From bertietf@bwijnen.net Tue Nov 1 01:42:49 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A625421F8FF4 for ; Tue, 1 Nov 2011 01:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wC06j5sLDzpr for ; Tue, 1 Nov 2011 01:42:49 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id E276321F8F9B for ; Tue, 1 Nov 2011 01:42:48 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RL9vg-0005Nu-8X for sidr@ietf.org; Tue, 01 Nov 2011 09:42:46 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RL9vf-0004S0-EA for sidr@ietf.org; Tue, 01 Nov 2011 09:42:43 +0100 Message-ID: <4EAFB103.4040407@bwijnen.net> Date: Tue, 01 Nov 2011 09:42:43 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sidr wg list References: <20111031130406.9489.27728.idtracker@ietfa.amsl.com> In-Reply-To: <20111031130406.9489.27728.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20111031130406.9489.27728.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4a515d0135ce10b06ad12a98acd761a51 Subject: [sidr] Fwd: New Version Notification for draft-ymbk-rpki-rtr-protocol-mib-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 08:42:49 -0000 Hi SIDR people, We have merged the two earlier MIB modules into one. It has undergone quite a set of changes. I think it would be good to review and discuss it at the upcoming IETF meeting. We have not yet defined the objects that extend the bgp4 MIB to show if a route is valid, invalid or notfound. That could possible also contain a set of counters. Anyway, that is work to be done. Bert -------- Original Message -------- Subject: New Version Notification for draft-ymbk-rpki-rtr-protocol-mib-02.txt Date: Mon, 31 Oct 2011 06:04:06 -0700 From: internet-drafts@ietf.org To: randy@psg.com CC: randy@psg.com, keyupate@cisco.com, michael.baer@sparta.com, bertietf@bwijnen.net A new version of I-D, draft-ymbk-rpki-rtr-protocol-mib-02.txt has been successfully submitted by Randy Bush and posted to the IETF repository. Filename: draft-ymbk-rpki-rtr-protocol-mib Revision: 02 Title: Definitions of Managed Objects for the RPKI-Router Protocol Creation date: 2011-10-31 WG ID: Individual Submission Number of pages: 23 Abstract: This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for monitoring the RPKI Router protocol. The IETF Secretariat From ietfc@btconnect.com Tue Nov 1 02:31:09 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550AD21F8F3A for ; Tue, 1 Nov 2011 02:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wScdyeqyueQz for ; Tue, 1 Nov 2011 02:31:08 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr07.btconnect.com [213.123.26.185]) by ietfa.amsl.com (Postfix) with ESMTP id D1B2E21F8F33 for ; Tue, 1 Nov 2011 02:31:04 -0700 (PDT) Received: from host86-163-151-98.range86-163.btcentralplus.com (HELO pc6) ([86.163.151.98]) by c2beaomr07.btconnect.com with SMTP id EZC84792; Tue, 01 Nov 2011 09:31:00 +0000 (GMT) Message-ID: <011c01cc986f$dc4c9520$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Bert Wijnen \(IETF\)" , "sidr wg list" References: <20111031130406.9489.27728.idtracker@ietfa.amsl.com> <4EAFB103.4040407@bwijnen.net> Date: Tue, 1 Nov 2011 09:25:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4EAFBC53.0005, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.11.1.84814:17:7.586, ip=86.163.151.98, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __FRAUD_SUBJ_A, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, __STOCK_PHRASE_24, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020D.4EAFBC56.016C,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: Re: [sidr] Fwd: New Version Notification fordraft-ymbk-rpki-rtr-protocol-mib-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 09:31:09 -0000 ----- Original Message ----- From: "Bert Wijnen (IETF)" To: "sidr wg list" Sent: Tuesday, November 01, 2011 9:42 AM > Hi SIDR people, > > We have merged the two earlier MIB modules into one. > It has undergone quite a set of changes. > I think it would be good to review and discuss it at the > upcoming IETF meeting. > > We have not yet defined the objects that extend the bgp4 MIB > to show if a route is valid, invalid or notfound. > That could possible also contain a set of counters. > Anyway, that is work to be done. Bert That makes me wonder what you would regard as the base MIB for bgp4. The idr WG has been updating it for over five years, and the topic surfaces occasionally on that list but I cannot recall anything for a year now, so what would the base be? (And yes, I like one I-D, one MIB module instead of two). Tom Petch > > Bert > > -------- Original Message -------- > Subject: New Version Notification for draft-ymbk-rpki-rtr-protocol-mib-02.txt > Date: Mon, 31 Oct 2011 06:04:06 -0700 > From: internet-drafts@ietf.org > To: randy@psg.com > CC: randy@psg.com, keyupate@cisco.com, michael.baer@sparta.com, bertietf@bwijnen.net > > A new version of I-D, draft-ymbk-rpki-rtr-protocol-mib-02.txt has been successfully submitted by Randy Bush and posted to the IETF > repository. > > Filename: draft-ymbk-rpki-rtr-protocol-mib > Revision: 02 > Title: Definitions of Managed Objects for the RPKI-Router Protocol > Creation date: 2011-10-31 > WG ID: Individual Submission > Number of pages: 23 > > Abstract: > This document defines a portion of the Management Information Base > (MIB) for use with network management protocols in the Internet > community. In particular, it describes objects used for monitoring > the RPKI Router protocol. > > > > > The IETF Secretariat > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > From kent@bbn.com Tue Nov 1 03:13:19 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E280F21F8F56 for ; Tue, 1 Nov 2011 03:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.892 X-Spam-Level: X-Spam-Status: No, score=-105.892 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUar8RvNgLKg for ; Tue, 1 Nov 2011 03:13:19 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3788521F8F53 for ; Tue, 1 Nov 2011 03:13:19 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:41761 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RLBKe-00089x-UC; Tue, 01 Nov 2011 06:12:37 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 31 Oct 2011 09:59:22 -0400 To: Terry Manderson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "draft-ietf-sidr-algorithm-agility@tools.ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 10:13:20 -0000 At 5:31 AM -0700 10/31/11, Terry Manderson wrote: >On 31/10/11 8:57 PM, "Stephen Kent" wrote: > >> At 7:18 PM -0700 10/30/11, Terry Manderson wrote: >> >> We have included dates for alg start an EOL because they affect all >> RPs, and we want to make life predictable for RPs. Also, because the >> WG agreed that alg transition will be top-down (to avoid geometric >> growth in the repository system), it is necessary to set alg >> transition dates, for the benefit of >> CAs as well. >> > >I understand why you want to, but don't come to the same conclusion as to >the mechanism. > >Is that really the IETF's job? SIDR was tasked by the SEc ADs to develop an alg transition architecture. The authors believe that uniform milestones are necessary as part of a credible plan. >Is there prior art in the IETF where this has been done in such a date >specific manner? Not sure. > >> [1] I would think that as soon at the document is updated and >published they >>> are able to be used. >> >> The top tier CAs have to be ready to issue certs under the new alg before >> any lower tier CAs can do so, so we need a set date, agreed upon, in >> the future, >> to start the transition. > >Call me a dirty rotten cynic but I just don't see this operational aspect of >one or more running RPKI hierarchies as part of the IETF. Although you can >prove me wrong, and I'll concede to an already enacted example where dates >were set for some artifact. We have to have two, parallel hierarchies to avoid a flag day. This is not a situation where every CA can decide, locally, when to transition, because the the alg change affect ALL RPs. > > We want to encourage RPs to verify their ability to use the new Suite, but > > we also realize that, during transition, there may be problems. So, >> we RECOMMEND use of Suite B, but require that if either Suite works, >> the RP MUST accept the data as valid. That provides a fall back >> position in case a CA doesn't get it right. >> > >In which case some clarification to the text could go a long way. I suspect >in the effort to simplify a complex process the text became too brief. OK. > >> issuance of suite C products MUST be considered invalid. >> >> we can revisit this text to try to make it clearer, if others agree with >> your observation. >> >>> Section 5. >>> >>> I think some discussion of the dates, and for communicating >>>twilight and EOL >>> dates between the parent and the child should be here. I don't quite hold >>> the belief that it's a unidirectional downward assertion from parent to >>> child. In may well be in PKI - there there is a raft of operational >>> interaction that surrounds that. >> >> The dates for alg transition are published and accessible to >> everyone, so there is no need for pairwise communication of the >> dates. Because the alg transition affects ALL RPs, not just the >> children of a given CA, it is important to mandate the transitions on >> a global basis. >> > >I'm still not with you on this - I understand that it makes life easy to say >"the IETF said 12/12/2018 is D-Day, get with it" .. ... buuuutt I see that >as a step beyond what the IETF should do. If not the IETF, then whom? The IETF (via SIDR) is the author of the CP. This is an extension of the CP, in many respects. > >> Section 6. >>> >>> Can you spell out what you technically mean by "keep any relationship >>> between " in para 1? >> >> We will revise this sentence. The text is intended to note that the >> data extracted from the repository, signed under each alg, are >> treated separately. Thus one gets a compete, valid chain of data via >> Suite A or Suite B, but not a mix of data under A and B. The next >> paragraph explains this. > >right, there is a discontinuous leap there that I didn't get. Clarification >would be appreciated. OK. > >> Section 7. > >> >>> Can you expand the recommendation in keeping the parallel certificate > >> hierarchies in sync by also identifying the Alg A/Alg C mix? (phase 4) >> >> In phase 4, Suite C products MAY be present, which means that they >> also may be absent. So, we cannot say that the hierarchies are >> parallel any more. > >So perhaps suggest to the RP/Child CA that in the situation where a >revocation is issued for Suite A, _if_ there are products with matching >information for the Suite A revocation, a Suite C revocation should also be >issued. If my coauthors agree, I think this could be added, Steve From bertietf@bwijnen.net Tue Nov 1 04:34:18 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA7A21F8EE3 for ; Tue, 1 Nov 2011 04:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.23 X-Spam-Level: X-Spam-Status: No, score=-102.23 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qy2TFdrCgy03 for ; Tue, 1 Nov 2011 04:34:18 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 2724921F8EDF for ; Tue, 1 Nov 2011 04:34:17 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RLCbe-0003pe-6K; Tue, 01 Nov 2011 12:34:15 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RLCbd-0003gF-Lj; Tue, 01 Nov 2011 12:34:14 +0100 Message-ID: <4EAFD935.3000803@bwijnen.net> Date: Tue, 01 Nov 2011 12:34:13 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "t.petch" References: <20111031130406.9489.27728.idtracker@ietfa.amsl.com> <4EAFB103.4040407@bwijnen.net> <011c01cc986f$dc4c9520$4001a8c0@gateway.2wire.net> In-Reply-To: <011c01cc986f$dc4c9520$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4feb9fd0b356be1e20e4f3bf0a4b7dbb2 Cc: sidr wg list Subject: Re: [sidr] Fwd: New Version Notification fordraft-ymbk-rpki-rtr-protocol-mib-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 11:34:18 -0000 On 11/1/11 9:25 AM, t.petch wrote: > Bert > > That makes me wonder what you would regard as the base MIB for bgp4. The idr WG > has been updating it for over five years, and the topic surfaces occasionally on > that list but I cannot recall anything for a year now, so what would the base > be? > > (And yes, I like one I-D, one MIB module instead of two). > > Tom Petch Hi Tom. That is a question I asked myself too. I found various troubles in the MIB module that is out a an I-D. So I was weary about extending that one, fearing that it may take too long to get that MIB module approved. It is I think up to the WG to decide which one they want to extend. It would be good if the newer module could be used, but since it is not making progress I wonder what the status is and if the/any WG participants actually intend to implement it. I did send an email to Jeff Haas to ask him about the status of that module. Sofar no response yet. Jeff, have you seen my email? Bert From wesley.george@twcable.com Tue Nov 1 05:32:29 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63E911E853D for ; Tue, 1 Nov 2011 05:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[AWL=0.730, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kABa9uJq2G9v for ; Tue, 1 Nov 2011 05:32:28 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id AC4C611E857E for ; Tue, 1 Nov 2011 05:32:28 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,437,1315195200"; d="scan'208";a="291936829" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 01 Nov 2011 08:28:24 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 1 Nov 2011 08:32:26 -0400 From: "George, Wes" To: Randy Bush Date: Tue, 1 Nov 2011 08:32:25 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-01.txt Thread-Index: AcyYGESaUdaQNmdnR2WNtZmRndQC8QAeeVXQ Message-ID: References: <20111019224523.16220.18338.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 12:32:29 -0000 > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > > Bgpsec-reqs 3.4 provides a list of operational considerations to > > discuss. Would probably make sense to ensure that the document covers > > all of the listed items, perhaps even using those items as section > > headings for continuity's sake. > > probably more appropriate in the protocol document, or an adjunct to it > > randy [WEG]] Not certain I understand. This is an operational considerations docu= ment, and those are listed as operational considerations. Why would that no= t be appropriate? How are you making the distinction between what is and is= not appropriate? Wes This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From randy@psg.com Tue Nov 1 05:36:46 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EF91F0C6C for ; Tue, 1 Nov 2011 05:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnCzsVjE+5XO for ; Tue, 1 Nov 2011 05:36:46 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id ECAFB1F0C59 for ; Tue, 1 Nov 2011 05:36:45 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RLDa8-000AOG-Sg; Tue, 01 Nov 2011 12:36:45 +0000 Date: Tue, 01 Nov 2011 13:36:43 +0100 Message-ID: From: Randy Bush To: "George, Wes" In-Reply-To: References: <20111019224523.16220.18338.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 12:36:46 -0000 >>> Bgpsec-reqs 3.4 provides a list of operational considerations to >>> discuss. Would probably make sense to ensure that the document covers >>> all of the listed items, perhaps even using those items as section >>> headings for continuity's sake. >> >> probably more appropriate in the protocol document, or an adjunct to it >> > [WEG]] Not certain I understand. This is an operational considerations document, and those are listed as operational considerations. Why would that not be appropriate? How are you making the distinction between what is and is not appropriate? Security Requirements for BGP Path Validation draft-ietf-sidr-bgpsec-reqs-01 Abstract This document describes requirements for a future BGP security protocol design ^^^^^^^^^^^^^^^ randy From kent@bbn.com Tue Nov 1 06:57:11 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDDE11E81B3 for ; Tue, 1 Nov 2011 06:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.38 X-Spam-Level: X-Spam-Status: No, score=-106.38 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyZBJBJRN2Tc for ; Tue, 1 Nov 2011 06:57:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id AB50711E8163 for ; Tue, 1 Nov 2011 06:57:09 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:35767 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RLEpw-000Amf-3c; Tue, 01 Nov 2011 09:57:09 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 1 Nov 2011 09:57:03 -0400 To: Danny McPherson From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-891966669==_ma============" Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 13:57:11 -0000 --============_-891966669==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 4:20 PM -0400 10/29/11, Danny McPherson wrote: >Some comments on sidr-bgpsec-threats-00 below.. > >Most substantial of my concerns is Section 5's "Residual >Vulnerabilities", specifically: > > "BGPSEC has a separate set of residual vulnerabilities: > > - BGPSEC is not able to prevent what is usually referred to as > route leaks, because BGP itself does not distinguish between > transit and non-transit ASes- BGPSEC signatures do not protect > all attributes associated with an AS_path. Some of these > attributes are employed as inputs to routing decisions. Thus > attacks that modify (or strip) these other attributes are not > detected by BGPSEC." > >Do we really consider it acceptable that the solution and machinery >we're recommending will NOT prevent "route leaks", Route leaks represent a violation of an ISPs local policy, i.e., the ISP is propagating routes that it, locally, did not intend to propagate. There is no semantic in BGP that captures this aspect of local policy. (The "NO EXPORT" community is not relevant here. An upstream or peer ISP may not know that the "leaking" ISP does not intend to export the routes in question. Also, the "leaking" ISP may legitimately plan to announce these routes to downstream ISPs.) So, since a route leak is an error only relative to the policy of the offending ISP BGPSEC cannot be expected to detect and reject this behavior. >and also does >NOT protect the integrity of the very path attributes that are used >to apply preferences (i.e., policy derived from business logic that >dictates most routing decisions on the Internet today)? I don't understand the text immediately above. Can you rephrase? >I'm having a really hard time subscribing to this as being an >acceptable residual threat after we reach full deployment, >particularly without a clear path outlining the development of >controls that mitigate that risk. BGPSEC (or any analogous technology) can provide protection for BGP relative to two constraints: - the semantics of BGP have to align with the protection - the underlying PKI has to align with the protection Thus, for example, other attributes carried by BGP and for which the resource allocation system has no reference, cannot be protected. Similarly, route leaks, because they are a violation of a local policy, which is not expressed in BGP Update messages, cannot be addressed. > >More comments below.... > >--- >s/to determine of/to determine if/ fixed >--- >In terminology section include "(AS)" after "Authonomous System" >per subsequent use of acronym. fixed >--- >s/AS Number (ANS)/AS Number (ASN)/ fixed. >--- >"False Origination" should probably be "network operator", not >ISP, in particular given the subsequent definition of ISP. please explain. >--- >s/Local Internet registries/Local Internet Registries/ fixed. >--- >The definition of "Route" seems to be missing the full set of >path attributes associated with the NLRI, it currently only >focuses on the AS_PATH attribute, and even omits the ORIGIN >code of the path. I think the definition does not omit the origin AS, but I will clarify the text. Our context assumes use of the RPKI, and the RPKI attests to only prefix and ASN holdings of entities, hence the focus on these attributes. For example, MPLS attributes are not supported in the RPKI, so they are out of scope here. >--- >Regarding your definition of "Threat": > > Threat - A threat is a motivated, capable adversary. An adversary > that is not motivated to launch an attack is not a threat. An > adversary that is motivated but not capable of launching an attack > also is not a threat. > >With many "route leaks" and similar incidents, the network operator >may not have been motivated to launch an attack, but the impact of a >leak is the same and it is certainly still a "threat". The definition I used here has been widely used for many years in contexts where folks understand the importance of distinguishing among attacks, adversaries, and motivations. Unlike the RPKI focus on config errors, BGPSEC focuses on attacks. As noted in above, route leaks are out of scope, because they do not represent violations of BGP semantics, as expressed externally. >--- >In "Threat Characterization" it would seem that for simplicity we >should refer to BGP speakers as "network operators", not just ISPs >as the current text suggests, particuarly in the case where an >attacker may well be a subscriber that intentionally interconnects >between two ISPs (in order to exploit business logic and derived >preferences), or leaks routes unintentionally as is commonly the >case today? I have made the suggested change. >--- >"Hackers might be recruited, without their knowledge, by criminals >or by nations, to act on their behalf." are you referring to social >engineering or other attacks here that would be employed to gain >access to a network operator's systems? If so, that doesn't make >the victim a "hacker"? I am referring to the adversaries, not to types of attacks. The target of a social engineering attack is not an adversary; he/she is an instrument used by an adversary. >--- >Wouldn't "attacker" be a better term here, "hacker" is fairly >ambiguous. Also, from a threat model perspective here I see little >difference between "criminals" and "nations", can you explain the >difference and why it's called out expressly anywhere beyond the >discussion of jurisdictional issues dictating network operator or >CA/INR functions? I think the motivation and capabilities discussion justifies the distinctions between these classes of adversaries. The term "attacker" is generic and not useful as an adversary characterization. >--- >Regarding "Registries", an attack on a registry in this case (e.g., >social engineering) could have the same or broader impacts as an >attack on an ISP (network operator), I think you capture this in >later sections but this text does not adequately represents this. I'll revisit this text. >--- >s/act as a rogue capacity/act in a rogue capacity/ ? fixed >--- >The end of Section 3 seems to be incomplete, i.e.: > >"A manifest associated with a CA's repository publication point > contains a list of: > >4. Attacks" yep. that was a whoops at my end. the manifest text should not have appeared there. >--- >Regarding Section 4.1, passive attacks, and "confidentiality" from >MITM as a non-goal, shouldn't protections there be an objective in >order to minimize the exposure of data that could lead to replay and >other similar attacks -- in order to further minimize that exposure >window we're trying to address with periodic updates? The mechanisms used to protect against replay attacks assume a MITM and knowledge of the plaintext. This is consistent with general IETF security analyses. >--- >This discusses TCP-AO or IPSec, whereas the rquirements draft avoids >TCP-AO and talks about TLS? I'm sure my text does not mention "IPSec" (vs. IPsec) :-). I will add TLS to the list. >--- >S 4.3: > >"This type of behavior cannot be externally detected as an attack." > >/cannot/may not/ I said "cannot" here because of the modifier "externally." To external observers, such behavior by an ISP may be viewed as odd behavior, but enough ISPs behave oddly enough to make this indistinguishable from an attack. >--- >"PA allocation" - Define PA here. I removed the "PA" qualifier. >--- >My read of most of the attacks in S 4.3 is about DoS-esque functions, >not certificate issuance that might be employed at a later time. >Perhaps we should capture this more clearly in this section, as it's >certainly one of the more obvious issues we're seeing with the CA >sieve today...? S 4.3 is titled "Attacks on ISP management computers (non-CA computers)" so CA-specific attacks do not belong in that section. S 4.5 addresses attacks focused on CAs. Not sure what you mean by "CA sieve." >--- >S 4.4 > >Regarding this text: > > "An RP can continue to use the last valid instance of the > deleted object as a local policy option), thus minimizing > the impact of such an attack." > >Such guidance and implementation may be precisely what an attacker >was hoping to instigate, no? Further: The RPKI and BGPSEC designs place a high priority on maintaining the ability of ISPs to continue routing in the face of outages. Using cached, previously validated RPKI data is a good way to support this goal, in the face of outages, benign or malicious. So, I think we are making an appropriate decision here. An attacker can always try to effect DoS on targeted RPs, and has has fewer attack options when RPs can revert to cached data. > "An RP cannot know the content of the new certificates or ROAs > that are not present, but it can continue to use what it has > cached." yes. >and S 5's Residual Vulnerabilities: > > - the RPKI repository system may be attacked in ways that make > its contents unavailable, or not current. It is anticipated that > RPs will cope with this vulnerability through local caching of > repository data, and through local settings that tolerate > expired or stale repository data. > >I think we should be clear that expired information should not be >used? I disagree. First, note that certs expire, but CRLs are defined as stale when the next issue date passes. Manifests are defined as stale when the bundled EE cert is expired. Other signed objects that have bundled EE certs expire with their certs. In the absence of current, valid objects, >--- >In the cases where notifying a CA of the error in order to remedy >the problem is the recommended action, what threats arise if the >CA cannot be reached or authenticated? Should those be enumerated >here? I assume this comment refers to the discussion in S 4.5, right? If the CA does not take action to remedy the attack effects, then the situation is equivalent to a CA as adversary (vs. attack victim). I will add a sentence to note this. >--- >S 5. > >s/were been discussed in the/were discussed in the/ fixed. >--- >I'm surprised I don't see anything here about timing dependencies >between RPKI and BGPSEC routers, and variances across a BGPSEC system >having considerable potential impacts. I think some discussion of >this is in order in a threats draft. There is no requirement that a BGPSEC router interact directly with the RPKI repository system. However, your question is still relevant if we substitute "local RPKI server" for "BGPSEC router." S 4.4 already deals with attacks against publication points, many of which are relevant to the timing concerns you cite above. The RPKI, is a distributed repository system with many maintainers. RPs ought not assume that they always have the very latest data from the system, and maintainers ought not assume that all RPs have the latest data. This issue is addressed in detail in the RPKI key rollover doc. >--- >Shouldn't there also be some discussion of coherency the RPKI >repository system? I.e., timing dependencies can result in some >amount of considerable exposure if a manifest or CRL regarding a >particular certificate have not been refreshed yet? Section 5 already addresses this, at a high level, see bold text: - the RPKI repository system may be attacked in ways that make its contents unavailable, or not current. It is anticipated that RPs will cope with this vulnerability through local caching of repository data, and through local settings that tolerate expired or stale repository data. I have changed this to say contents unavailable, not current current, or inconsistent. Steve --============_-891966669==_ma============ Content-Type: text/html; charset="us-ascii" Re: [sidr] BGPSEC Threat Model ID
At 4:20 PM -0400 10/29/11, Danny McPherson wrote:
Some comments on sidr-bgpsec-threats-00 below..

Most substantial of my concerns is Section 5's "Residual
Vulnerabilities", specifically:

 "BGPSEC has a separate set of residual vulnerabilities:

  - BGPSEC is not able to prevent what is usually referred to as
    route leaks, because BGP itself does not distinguish between
    transit and non-transit ASes- BGPSEC signatures do not protect
    all attributes associated with an AS_path. Some of these
    attributes are employed as inputs to routing decisions. Thus
    attacks that modify (or strip) these other attributes are not
    detected by BGPSEC."

Do we really consider it acceptable that the solution and machinery
we're recommending will NOT prevent "route leaks",

Route leaks represent a violation of an ISPs local policy, i.e., the ISP
is propagating routes that it, locally, did not intend to propagate. There is no semantic in BGP that captures this aspect of local policy. (The "NO EXPORT" community is not relevant here. An upstream or peer ISP may not know that the "leaking" ISP does not intend to export the routes in question. Also, the "leaking" ISP may legitimately plan to announce these routes to downstream ISPs.) So, since a route leak is an error only relative to the policy of the
offending ISP  BGPSEC cannot be expected to detect and reject this behavior.


and also does
NOT protect the integrity of the very path attributes that are used
to apply preferences (i.e., policy derived from business logic that
dictates most routing decisions on the Internet today)?

I don't understand the text immediately above. Can you rephrase?

I'm having a really hard time subscribing to this as being an
acceptable residual threat after we reach full deployment,
particularly without a clear path outlining the development of
controls that mitigate that risk.

BGPSEC (or any analogous technology) can provide protection for BGP relative to
two constraints:
        - the semantics of BGP have to align with the protection
        - the underlying PKI has to align with the protection

Thus, for example, other attributes carried by BGP and for which the resource
allocation system has no reference, cannot be protected. Similarly, route leaks, because they are a violation of a local policy, which is not expressed in BGP Update messages, cannot be addressed.


More comments below....

---
s/to determine of/to determine if/

fixed
---
In terminology section include "(AS)" after "Authonomous System"
per subsequent use of acronym.

fixed
---
s/AS Number (ANS)/AS Number (ASN)/

fixed.
---
"False Origination" should probably be "network operator", not
ISP, in particular given the subsequent definition of ISP.

please explain.

---
s/Local Internet registries/Local Internet Registries/

fixed.

---
The definition of "Route" seems to be missing the full set of
path attributes associated with the NLRI, it currently only
focuses on the AS_PATH attribute, and even omits the ORIGIN
code of the path.

I think the definition does not omit the origin AS, but I will clarify the text.
Our context assumes use of the RPKI, and the RPKI attests to only prefix and ASN holdings of entities, hence the focus on these attributes. For example, MPLS attributes are not supported in the RPKI, so they are out of scope here.

---
Regarding your definition of "Threat":

   Threat - A threat is a motivated, capable adversary. An adversary
   that is not motivated to launch an attack is not a threat. An
   adversary that is motivated but not capable of launching an attack
   also is not a threat.

With many "route leaks" and similar incidents, the network operator
may not have been motivated to launch an attack, but the impact of a
leak is the same and it is certainly still a "threat".

The definition I used here has been widely used for many years in contexts
where folks understand the importance of distinguishing among attacks,  adversaries, and motivations. Unlike the RPKI focus on config errors, BGPSEC
focuses on attacks. As noted in above, route leaks are out of scope, because
they do not represent violations of BGP semantics, as expressed externally.

---
In "Threat Characterization" it would seem that for simplicity we
should refer to BGP speakers as "network operators", not just ISPs
as the current text suggests, particuarly in the case where an
attacker may well be a subscriber that intentionally interconnects
between two ISPs (in order to exploit business logic and derived
preferences), or leaks routes unintentionally as is commonly the
case today?

I have made the suggested change.

---
"Hackers might be recruited, without their knowledge, by criminals
or by nations, to act on their behalf." are you referring to social
engineering or other attacks here that would be employed to gain
access to a network operator's systems?  If so, that doesn't make
the victim a "hacker"?

I am referring to the adversaries, not to types of attacks. The target
of a social engineering attack is not an adversary; he/she is an instrument
used by an adversary.

---
Wouldn't "attacker" be a better term here, "hacker" is fairly
ambiguous.  Also, from a threat model perspective here I see little
difference between "criminals" and "nations", can you explain the
difference and why it's called out expressly anywhere beyond the
discussion of jurisdictional issues dictating network operator or
CA/INR functions?

I think the motivation and capabilities discussion justifies the distinctions between these classes of adversaries. The term "attacker" is generic and not
useful as an adversary characterization.

---
Regarding "Registries", an attack on a registry in this case (e.g.,
social engineering) could have the same or broader impacts as an
attack on an ISP (network operator), I think you capture this in
later sections but this text does not adequately represents this.

I'll revisit this text.
---
s/act as a rogue capacity/act in a rogue capacity/ ?

fixed
---
The end of Section 3 seems to be incomplete, i.e.:

"A manifest associated with a CA's repository publication point
 contains a list of:

4. Attacks"


yep. that was a whoops at my end. the manifest text should not have
appeared there.


---
Regarding Section 4.1, passive attacks, and "confidentiality" from
MITM as a non-goal, shouldn't protections there be an objective in
order to minimize the exposure of data that could lead to replay and
other similar attacks -- in order to further minimize that exposure
window we're trying to address with periodic updates?

The mechanisms used to protect against replay attacks assume a MITM and
knowledge of the plaintext. This is consistent with general IETF security
analyses.

---
This discusses TCP-AO or IPSec, whereas the rquirements draft avoids
TCP-AO and talks about TLS?

I'm sure my text does not mention "IPSec" (vs. IPsec) :-). I will add
TLS to the list.


---
S 4.3:

"This type of behavior cannot be externally detected as an attack."

/cannot/may not/

I said "cannot" here because of the modifier "externally." To external
observers, such behavior by an ISP may be viewed as odd behavior, but enough ISPs
behave oddly enough to make this indistinguishable from an attack.

---
"PA allocation" - Define PA here.

I removed the "PA" qualifier.

---
My read of most of the attacks in S 4.3 is about DoS-esque functions,
not certificate issuance that might be employed at a later time.
Perhaps we should capture this more clearly in this section, as it's
certainly one of the more obvious issues we're seeing with the CA
sieve today...?

S 4.3 is titled "Attacks on ISP management computers (non-CA computers)" so CA-specific attacks do not belong in that section. S 4.5 addresses attacks focused on CAs.

Not sure what you mean by "CA sieve."

---
S 4.4

Regarding this text:

  "An RP can continue to use the last valid instance of the
   deleted object as a local policy option), thus minimizing
   the impact of such an attack."

Such guidance and implementation may be precisely what an attacker
was hoping to instigate, no?  Further:

The RPKI and BGPSEC designs place a high priority on maintaining
the ability of ISPs to continue routing in the face of outages. Using cached, previously validated RPKI data is a good way to support this goal, in the face of outages, benign or malicious. So, I think we are making an appropriate decision here. An attacker can always try to effect DoS on targeted RPs, and has has fewer attack options when RPs can revert to cached data.


  "An RP cannot know the content of the new certificates or ROAs
   that are not present, but it can continue to use what it has
   cached."

yes.
and S 5's Residual Vulnerabilities:

   - the RPKI repository system may be attacked in ways that make
   its contents unavailable, or not current. It is anticipated that
   RPs will cope with this vulnerability through local caching of
   repository data, and through local settings that tolerate
   expired or stale repository data.

I think we should be clear that expired information should not be
used?

I disagree. First, note that certs expire, but CRLs are defined as stale when the next issue date passes.  Manifests are defined as stale when the bundled EE cert is expired. Other signed objects that have bundled EE certs expire with their certs. In the absence of current, valid objects,

---
In the cases where notifying a CA of the error in order to remedy
the problem is the recommended action, what threats arise if the
CA cannot be reached or authenticated?  Should those be enumerated
here?

I assume this comment refers to the discussion in S 4.5, right?  If the CA does not
take action to remedy the attack effects, then the situation is equivalent to
a CA as adversary (vs. attack victim). I will add a sentence to note this.

---
S 5.

s/were been discussed in the/were discussed in the/

fixed.
---
I'm surprised I don't see anything here about timing dependencies
between RPKI and BGPSEC routers, and variances across a BGPSEC system
having considerable potential impacts.  I think some discussion of
this is in order in a threats draft.

There is no requirement that a BGPSEC router interact directly with the RPKI repository system. However, your question is still relevant if we substitute
"local RPKI server" for "BGPSEC router." S 4.4 already deals with attacks against publication points, many of which are relevant to the timing concerns you cite above. The RPKI, is a distributed repository system with many maintainers. RPs ought not assume that they always have the very latest data from the system, and maintainers ought not assume that all RPs have the latest data.  This issue is addressed in detail in the RPKI key rollover doc.

---
Shouldn't there also be some discussion of coherency the RPKI
repository system?  I.e., timing dependencies can result in some
amount of considerable exposure if a manifest or CRL regarding a
particular certificate have not been refreshed yet?


Section 5 already addresses this, at a high level, see bold text:

        - the RPKI repository system may be attacked in ways that make
        its contents unavailable, or not current. It is anticipated that
        RPs will cope with this vulnerability through local caching of
        repository data, and through local settings that tolerate
        expired or stale repository data.

I have changed this to say

        contents unavailable, not current current, or inconsistent.

Steve
--============_-891966669==_ma============-- From mlepinski@bbn.com Tue Nov 1 10:01:35 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3FF21F8461 for ; Tue, 1 Nov 2011 10:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZXy9a6aqKGe for ; Tue, 1 Nov 2011 10:01:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id CA3E721F844D for ; Tue, 1 Nov 2011 10:01:34 -0700 (PDT) Received: from [128.89.255.45] (port=1354) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RLHgE-000F6B-M3 for sidr@ietf.org; Tue, 01 Nov 2011 12:59:19 -0400 Message-ID: <4EB02586.5010101@bbn.com> Date: Tue, 01 Nov 2011 12:59:50 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sidr@ietf.org References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> In-Reply-To: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 17:01:35 -0000 I have updated the BGPSEC protocol specification. At the SIDR meeting in Quebec, there was significant discussion about how BGPSEC could provide security of the AS-PATH attribute while still accommodating the needs of route servers that participate in BGP, but do not wish to increase the length of the AS-PATH attribute. The -01 version of the draft contains a mechanism (a field called pCount) which attempts to address this issue by having route servers create BGPSEC signatures without increasing the effective length of the AS-PATH attribute. I would greatly appreciate comments on this mechanism and whether it adequately addresses the issues raised at the last SIDR meeting and subsequently discussed on the list. There was has also been significant discussion on the SIDR list of the "Expire TIme" field in BGPSEC and the associated "Beacon-ing" (that is, periodic re-advertisement of a prefix with a new signature and a new Expire Time) as a mechanism to address replay attacks (as well as attacks where a malicious peer fails to propagate the withdrawal of a route). My understanding is that the consensus of the working group was that the current Expire Time mechanism is reasonable as long as re-advertisement is only required at the origin AS (and not at intermediate ASes). The current -01 version of the draft attempts to reflect that consensus. Finally, there are a number of small editorial changes that I believe will improve the clarity of the draft. Thanks again to everyone who has reviewed the document, feedback on how the text could be made more easily understandable is especially welcome. - Matt Lepinski On 10/31/2011 3:38 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. > > Title : BGPSEC Protocol Specification > Author(s) : Matthew Lepinski > Filename : draft-ietf-sidr-bgpsec-protocol-01.txt > Pages : 28 > Date : 2011-10-31 > > This document describes BGPSEC, an extension to the Border Gateway > Protocol (BGP) that provides security for the AS-PATH attribute in > BGP update messages. BGPSEC is implemented via a new optional non- > transitive BGP path attribute that carries a digital signature > produced by each autonomous system on the AS-PATH. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-protocol-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-protocol-01.txt > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From danny@tcb.net Tue Nov 1 11:22:58 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EB011E80E6 for ; Tue, 1 Nov 2011 11:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vd1K0GmnC8AV for ; Tue, 1 Nov 2011 11:22:56 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id CF50411E80C9 for ; Tue, 1 Nov 2011 11:22:56 -0700 (PDT) Received: from webmail.tcb.net (localhost.localdomain [127.0.0.1]) by dog.tcb.net (Postfix) with ESMTP id 016A526800D; Tue, 1 Nov 2011 12:09:31 -0600 (MDT) Received: from 216.168.239.87 (SquirrelMail authenticated user dpop@tcb.net) by webmail.tcb.net with HTTP; Tue, 1 Nov 2011 14:09:32 -0400 (EDT) Message-ID: <4548.216.168.239.87.1320170972.squirrel@webmail.tcb.net> In-Reply-To: <4EB02586.5010101@bbn.com> References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com> Date: Tue, 1 Nov 2011 14:09:32 -0400 (EDT) From: "Danny McPherson" To: "Matt Lepinski" User-Agent: SquirrelMail/1.4.10a-1.fc6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: danny@tcb.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 18:22:58 -0000 > At the SIDR meeting in Quebec, there was significant discussion about > how BGPSEC could provide security of the AS-PATH attribute while still > accommodating the needs of route servers that participate in BGP, but do > not wish to increase the length of the AS-PATH attribute. The -01 > version of the draft contains a mechanism (a field called pCount) which > attempts to address this issue by having route servers create BGPSEC > signatures without increasing the effective length of the AS-PATH > attribute. I would greatly appreciate comments on this mechanism and > whether it adequately addresses the issues raised at the last SIDR > meeting and subsequently discussed on the list. If we do this we're disclosing routing topology information that is NOT disclosed today (i.e., an otherwise transparent route server in the BGP path). IIRC, not disclosing new information was an explicit requirement? > There was has also been significant discussion on the SIDR list of the > "Expire TIme" field in BGPSEC and the associated "Beacon-ing" (that is, > periodic re-advertisement of a prefix with a new signature and a new > Expire Time) as a mechanism to address replay attacks (as well as > attacks where a malicious peer fails to propagate the withdrawal of a > route). My understanding is that the consensus of the working group was > that the current Expire Time mechanism is reasonable as long as > re-advertisement is only required at the origin AS (and not at > intermediate ASes). The current -01 version of the draft attempts to > reflect that consensus. Can you provide a pointer to where this was discussed AND consensus was reached in the WG, I don't recall seeing any consensus and I'm still very concerned about adding periodic updates and considerable churn to an otherwise stateful system in order to minimize exposure windows to multiple hours (or more). Furthermore, given the systemic and architectural implications of such a mechanism, I would like to see an explicit consensus call on this item from the chairs. I also think this is something that should be consulted with the IDR WG, as periodic updates ("beacons") are a considerable step away from the stateful BGP we know today -- and when coupled with single NLRI-only UPDATES an order of magnitude or larger that require cryptographic validation of many component elements, it makes me uneasy. -danny From brian.peter.dickson@gmail.com Tue Nov 1 11:34:51 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75FC21F8E33 for ; Tue, 1 Nov 2011 11:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFvdV1CvSKc3 for ; Tue, 1 Nov 2011 11:34:51 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9562621F8C37 for ; Tue, 1 Nov 2011 11:34:25 -0700 (PDT) Received: by faas12 with SMTP id s12so8037334faa.31 for ; Tue, 01 Nov 2011 11:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cDi/yZZezEn9QZHvsa3oMs16uSwaKfHlcmYvMd+yu+8=; b=TXMa1+Nv8/1wpWfwsED0SV1JBeQAn+iTGDKSOby3/Ym+o2fsDPutj5qdHACq3RVMf+ GTe21ILl6Rk89ZP22oCKxQ0cQPwT1DbyCEANj0YKCwUIxTByia1b+0vl8ppd990AS7hk SQEqMUbdAj7DEUaJP1aUKG83vCTQK5mMHZE9E= MIME-Version: 1.0 Received: by 10.223.5.82 with SMTP id 18mr2307688fau.27.1320172445033; Tue, 01 Nov 2011 11:34:05 -0700 (PDT) Received: by 10.223.54.15 with HTTP; Tue, 1 Nov 2011 11:34:04 -0700 (PDT) In-Reply-To: <4EB02586.5010101@bbn.com> References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com> Date: Tue, 1 Nov 2011 14:34:04 -0400 Message-ID: From: Brian Dickson To: Matt Lepinski Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 18:34:52 -0000 I've read the draft, and find it to be very high quality and very clear. The one comment I have regarding pCount, is in regards to processing received pCount=3D0 announcements. I believe the concerns regarding "AS-path cheating" to attract traffic, by using pCount=3D0, could be addressed with some special handling. Basically, when receiving pCount=3D0 at the top of the stack (most recent addition, by one's peer), checking the next-hop to ensure it satisfies "three-routing" requirements, i.e. that the next hop be something other than the neighbor's IP address, is sufficient. The only other suggestion is related to the number of signature blocks. I agree that support for two is needed at a minimum. I am not entirely sure that restricting it to two is necessary, but haven't thought through the scenarios here. Perhaps "one or more" rather than "one or two"? Has there been any thought to use of a cryptographically signed "Expire Time" (which can be sent and updated as a keep-alive/add-time-to-the-meter mechanism), and then having the blocks refer to the Expire Time by reference (and have the reference internally by pointer, originally matching a cryptographic hash on the first received timer, whose pointed-to value gets updated)? This reduces the "beacon" issue to updating a single value, and limits the playback to the interval during which the original Expire Time exists. Newer updates would refer to the latest cryptographic hash of the last sent Expire Time (update). It becomes a chaining exercise in a state-ful environment... Brian On Tue, Nov 1, 2011 at 12:59 PM, Matt Lepinski wrote: > I have updated the BGPSEC protocol specification. > > At the SIDR meeting in Quebec, there was significant discussion about how > BGPSEC could provide security of the AS-PATH attribute while still > accommodating the needs of route servers that participate in BGP, but do = not > wish to increase the length of the AS-PATH attribute. The -01 version of = the > draft contains =A0a mechanism (a field called pCount) which attempts to > address this issue by having route servers create BGPSEC signatures witho= ut > increasing the effective length of the AS-PATH attribute. I would greatly > appreciate comments on this mechanism and whether it adequately addresses > the issues raised at the last SIDR meeting and subsequently discussed on = the > list. > > There was has also been significant discussion on the SIDR list of the > "Expire TIme" field in BGPSEC and the associated "Beacon-ing" (that is, > periodic re-advertisement of a prefix with a new signature and a new Expi= re > Time) as a mechanism to address replay attacks (as well as attacks where = a > malicious peer fails to propagate the withdrawal of a route). My > understanding is that the consensus of =A0the working group was that the > current Expire Time mechanism is reasonable as long as re-advertisement i= s > only required at the origin AS (and not at intermediate ASes). The curren= t > -01 version of the draft attempts to reflect that consensus. > > Finally, there are a number of small editorial changes that I believe wil= l > improve the clarity of the draft. Thanks again to everyone who has review= ed > the document, feedback on how the text could be made more easily > understandable is especially welcome. > > - Matt Lepinski > > > > > On 10/31/2011 3:38 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Secure Inter-Domain Routin= g >> Working Group of the IETF. >> >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : BGPSEC Protocol Specification >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Matthew Lepinski >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-sidr-bgpsec-protocol= -01.txt >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 28 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-10-31 >> >> =A0 =A0This document describes BGPSEC, an extension to the Border Gatewa= y >> =A0 =A0Protocol (BGP) that provides security for the AS-PATH attribute i= n >> =A0 =A0BGP update messages. =A0BGPSEC is implemented via a new optional = non- >> =A0 =A0transitive BGP path attribute that carries a digital signature >> =A0 =A0produced by each autonomous system on the AS-PATH. >> >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-protocol-01.t= xt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-protocol-01.tx= t >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From danny@tcb.net Tue Nov 1 12:52:33 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A8821F8F44 for ; Tue, 1 Nov 2011 12:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fHiwr0BC-Xg for ; Tue, 1 Nov 2011 12:52:31 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id D133C21F8D1D for ; Tue, 1 Nov 2011 12:52:31 -0700 (PDT) Received: from webmail.tcb.net (localhost.localdomain [127.0.0.1]) by dog.tcb.net (Postfix) with ESMTP id AE1CB26800D; Tue, 1 Nov 2011 13:27:37 -0600 (MDT) Received: from 216.168.239.87 (SquirrelMail authenticated user dpop@tcb.net) by webmail.tcb.net with HTTP; Tue, 1 Nov 2011 15:27:37 -0400 (EDT) Message-ID: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> In-Reply-To: References: Date: Tue, 1 Nov 2011 15:27:37 -0400 (EDT) From: "Danny McPherson" To: "Stephen Kent" User-Agent: SquirrelMail/1.4.10a-1.fc6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: danny@tcb.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 19:52:33 -0000 > Route leaks represent a violation of an ISPs local policy, i.e., the ISP > is propagating routes that it, locally, did not intend to propagate. Perhaps the network operator DID fully intend to propagate ("leak") those routes in order to hijack and MITM traffic? Any multi-homed customer can launch such an attack today of this sort, and as a matter of fact, it happens all the time, for benign or malicious purposes. To say that this is not a "semantics violation" and therefore in scope does not mitigate the risk. How that risk can be considered as a "Residual Risk" in a "Threat Model for BGP Path Security" document totally escapes me? > BGPSEC (or any analogous technology) can provide protection for BGP > relative to two constraints: > - the semantics of BGP have to align with the protection > - the underlying PKI has to align with the protection > > Thus, for example, other attributes carried by BGP and for which the > resource allocation system has no reference, cannot be protected. > Similarly, route leaks, because they are a violation of a local policy, > which is not expressed in BGP Update messages, cannot be addressed. But they are certainly still risks, whether the proposals at hand can mitigate them or not is orthogonal. And even policy expressed in IRRs and via RPSL can result in controls that can be put in place to mitigate various aspects of those risk. I don't understand how we can ignore this as an objective here, and we certainly cannot discard it so casually as a trivial residual threat. If some non-obvious or undisclosed roadmap exists to solve this piece then I'm truly anxious to see it - else it would seem to me secure IRRs bootstrapped by resource certification data and perhaps even deployed to routers via some rpki-rtr-esque protocol would provide a lot better protection with a lot less overhead. >>--- >>"False Origination" should probably be "network operator", not >>ISP, in particular given the subsequent definition of ISP. > > please explain. You use ISP in this draft as if they're the only ones who may be multi-homed or trigger leaks or other functions, "network operator" is much more broadly applicable and well beyond "ISP" in the traditional sense. >>--- >>The definition of "Route" seems to be missing the full set of >>path attributes associated with the NLRI, it currently only >>focuses on the AS_PATH attribute, and even omits the ORIGIN >>code of the path. > > I think the definition does not omit the origin AS, but I will > clarify the text. I'm not talking about Origin AS, I'm talking about "ORIGIN Type Code" Path Attribute (i.e., i, e, or ?). > Our context assumes use of the RPKI, and the RPKI attests to only > prefix and ASN holdings of entities, hence the focus on these > attributes. For example, MPLS attributes are not supported in the > RPKI, so they are out of scope here. I think the "Threat Model" document should give consideration to Path Attributes beyond just AS_PATH, particularly because most are used in path selection. If we think we don't need to protect these because they are not in RPKI, then we should consider what that means rather than assume RPKI contains the information for all that we need to protect. > The definition I used here has been widely used for many years > in contexts where folks understand the importance of > distinguishing among attacks, adversaries, and motivations. > Unlike the RPKI focus on config errors, BGPSEC focuses on attacks. > As noted in above, route leaks are out of scope, because they > do not represent violations of BGP semantics, as expressed > externally. If Enterprise_E is multi-homed to ISP_1 and ISP_2 and is a transit customer of both, and then decides (or is compromised and used to decide) that he wants to hijack traffic from ISP_1 towards ISP_2 for Prefix_P by announcing ISP_2's Enterprise_E2 Prefix_P to ISP_1 through Enterprise_E's local interconnect, and "policy" makes it a more preferred path, how is this not an attack? And it's most certainly a threat and one that some consider out of scope at that? > I think the motivation and capabilities discussion justifies the > distinctions between these classes of adversaries. The term > "attacker" is generic and not useful as an adversary > characterization. Contextual use "attacker" is more generic than "hacker"? Umm, ok, I'm not attached to either.. > >>--- >>S 4.3: >> >>"This type of behavior cannot be externally detected as an attack." >> >>/cannot/may not/ > > I said "cannot" here because of the modifier "externally." To external > observers, such behavior by an ISP may be viewed as odd behavior, but > enough ISPs behave oddly enough to make this indistinguishable from > an attack. But it "may" be externally detectable, which was my point that you've reinforced :-) >>Such guidance and implementation may be precisely what an attacker >>was hoping to instigate, no? Further: > > The RPKI and BGPSEC designs place a high priority on maintaining > the ability of ISPs to continue routing in the face of outages. Using > cached, previously validated RPKI data is a good way to support this > goal, in the face of outages, benign or malicious. So, I think we are > making an appropriate decision here. An attacker can always try to > effect DoS on targeted RPs, and has has fewer attack options when RPs > can revert to cached data. While I agree, this can enable downgrade or other attacks, no? Just like clicking on that self-signed or expired intermediate CA certificate warning in a web browser, right? If so, the threat model should indicate as such. > I disagree. First, note that certs expire, but CRLs are defined as > stale when the next issue date passes. Manifests are defined as > stale when the bundled EE cert is expired. Other signed objects that > have bundled EE certs expire with their certs. In the absence of > current, valid objects, OK, see above.. Going through all this effort, and then using "expired data" just seems dirty and opens up a bunch of ugliness to me... >>--- >>I'm surprised I don't see anything here about timing dependencies >>between RPKI and BGPSEC routers, and variances across a BGPSEC system >>having considerable potential impacts. I think some discussion of >>this is in order in a threats draft. > > There is no requirement that a BGPSEC router interact directly with > the RPKI repository system. However, your question is still relevant > if we substitute > "local RPKI server" for "BGPSEC router." S 4.4 already deals with > attacks against publication points, many of which are relevant to the > timing concerns you cite above. The RPKI, is a distributed repository > system with many maintainers. RPs ought not assume that they always > have the very latest data from the system, and maintainers ought not > assume that all RPs have the latest data. This issue is addressed in > detail in the RPKI key rollover doc. But it's a threat and this is the threat document, right? If we're not going to include it here we should at least reference those sections. > > Section 5 already addresses this, at a high level, see bold text: > > - the RPKI repository system may be attacked in ways that make > its contents unavailable, or not current. It is anticipated that > RPs will cope with this vulnerability through local caching of > repository data, and through local settings that tolerate > expired or stale repository data. > > I have changed this to say > > contents unavailable, not current current, or inconsistent. Not current == expired. I'll defer to crypto types here, but as a first order function, I would like to see explicit text and reach agreement that expired data should be used in the absence of current data, and what the attack surface implications of using expired data are. As usual, thanks for the thoughtful responses Steve. I really am trying to come to grips with what's being proposed, but I'm just not there on the cost/benefit analysis at the moment. -danny From wesley.george@twcable.com Tue Nov 1 14:30:21 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0660811E80A2 for ; Tue, 1 Nov 2011 14:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.767 X-Spam-Level: X-Spam-Status: No, score=-0.767 tagged_above=-999 required=5 tests=[AWL=0.696, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2bmYfNH+-dk for ; Tue, 1 Nov 2011 14:30:20 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF2911E809C for ; Tue, 1 Nov 2011 14:30:20 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,438,1315195200"; d="scan'208";a="292132830" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 01 Nov 2011 14:01:49 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 1 Nov 2011 14:05:52 -0400 From: "George, Wes" To: "sidr@ietf.org" Date: Tue, 1 Nov 2011 14:05:51 -0400 Thread-Topic: 4-byte vs 2 byte ASN (was re: I-D Action: draft-ietf-sidr-pfx-validate-03.txt) Thread-Index: AcyX+dk9b8n5fxH8QzGzzXqJPGmKMgAxG48A Message-ID: References: <20111031182058.24592.70473.idtracker@ietfa.amsl.com> In-Reply-To: <20111031182058.24592.70473.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] 4-byte vs 2 byte ASN (was re: I-D Action: draft-ietf-sidr-pfx-validate-03.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 21:30:21 -0000 Posing the question about 4-byte ASNs in my review of the BGPSec design req= s draft yesterday makes me wonder about the same in pfx-validate. The draft= makes reference to AS_PATH in several locations. I'm thinking that we need= a comment early in the draft stating that for the remainder of the draft n= o distinction is being made between AS_PATH and AS4_PATH, and that this sta= ndard is expected to support origin validation of both. Or alternatively, s= pecify that this validation is performed on AS4_PATH and require support fo= r 4893 as a prerequisite for SIDR. If we don't explicitly require hosts that support SIDR origin validation to= support 4-byte ASN, we may also need some direction regarding specific han= dling for AS23456, such as to always treat as unknown since there is no way= to determine validity for the combination of a prefix and a non-unique pla= ceholder ASN (except for local TA), but we don't necessarily want those rou= tes to be treated as invalid. I'm not sure if some of this belongs within sidr-arch, roa-validation, orig= in-ops, etc, but a quick scan through those docs don't reveal any obvious r= eferences to 4893, AS4_PATH, etc. Thanks Wes George > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Monday, October 31, 2011 2:21 PM > To: i-d-announce@ietf.org > Cc: sidr@ietf.org > Subject: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-03.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Secure Inter-Domain > Routing Working Group of the IETF. > > Title : BGP Prefix Origin Validation > Author(s) : Pradosh Mohapatra > John Scudder > David Ward > Randy Bush > Rob Austein > Filename : draft-ietf-sidr-pfx-validate-03.txt > Pages : 13 > Date : 2011-10-31 > > To help reduce well-known threats against BGP including prefix mis- > announcing and monkey-in-the-middle attacks, one of the security > requirements is the ability to validate the origination AS of BGP > routes. More specifically, one needs to validate that the AS number > claiming to originate an address prefix (as derived from the AS_PATH > attribute of the BGP route) is in fact authorized by the prefix > holder to do so. This document describes a simple validation > mechanism to partially satisfy this requirement. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-pfx-validate-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-pfx-validate-03.txt > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From brian.peter.dickson@gmail.com Tue Nov 1 15:45:05 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55D31F0C5B for ; Tue, 1 Nov 2011 15:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu2Q+DvoZs4h for ; Tue, 1 Nov 2011 15:45:05 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id AF7AF1F0C36 for ; Tue, 1 Nov 2011 15:45:04 -0700 (PDT) Received: by faas12 with SMTP id s12so8270296faa.31 for ; Tue, 01 Nov 2011 15:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CXM29YWn/Hyyf0yv5nieOG2HCoi0u5coVT1oMbT5dzE=; b=LYG+CI3UfMrSwesIrJiXESyokfXADDsw0C+yF1dQzOnDcQeqzY8XsxjzCBS7wsAsbR i0wZJcuLeIf+yWzP5brjMpiEDlTFQarnNUaVc+ZYWiEkRIpiQDh5XmJ5aNhN9dOKD+aS P1LPw6CJz2+Ojd05qq9AMdJWn/oenRkTnNlFI= MIME-Version: 1.0 Received: by 10.223.5.82 with SMTP id 18mr3650311fau.27.1320187503863; Tue, 01 Nov 2011 15:45:03 -0700 (PDT) Received: by 10.223.54.15 with HTTP; Tue, 1 Nov 2011 15:45:03 -0700 (PDT) Date: Tue, 1 Nov 2011 18:45:03 -0400 Message-ID: From: Brian Dickson To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: [sidr] BGPsec - proposal for threat model, protocol, requirements X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 22:45:06 -0000 I have a proposal, to address the route-leak issue. It necessarily requires changes to all of the following documents, if it is adopted: - threat model - protocol - requirements - NB: this proposed element does not have a corresponding value in vanilla = BGP. - (If BGP had this already, there would not be any route leaks.) Here is what I propose: Add an announced Path Attribute, "Transit", to every BGPSEC signature block on an announced prefix. "Transit" is a flag bit, and applies to the _announcement_ between ASNs in the path. Include this Transit flag in the set of things that are signed. Make this attribute mandatory to BGPSEC, applied to every signature block on a route. Every BGPSEC peering session is either Transit, or Not-Transit, from the perspective of the local AS. For BGPSEC speakers A and B, all four combinations are legitimate scenarios= : A and B are "strictly speaking, peers" - e.g. 'tier-1' networks A and B: - A->B is "not-transit" - B->A is "not-transit" A provides transit to B (or vice versa; exchange labels A and B): - A->B is "not-transit" - B->A is "transit" A and B provide "mutual backup transit": - A->B is "transit" - B->A is "transit" The last scenario *should* be extremely rare. The last scenario happens to also be the default behavior for BGP when unconstrained routing announcements exist, i.e. inexperienced network engineers are given "enable" and asked to "do BGP". Here are the specific details and semantics, that in general make "the right thing" happen, and stop route leaks from happening, whether by accident or design. 1) The "transit" bit can be demoted to "not-transit" (on received, signed BGPSEC routes). 2) The "transit" bit cannot be promoted from "not-transit" to "transit" (on received, signed BGPSEC routes). 3) Routes can be originated as "transit" or "not-transit". The sensible default behavior is "transit". 4) Routes that are received, under a default configuration, SHOULD be demoted to "non-transit". 4a) Transit ISPs MUST change the (default) configuration on their customers' BGP sessions to not-demote their customers' routes. 4b) Mutual-Transit arrangements MUST change the (default) configuration to not-demote their respective routes. 5a) A route with the "transit" bit MAY be sent over any BGPSEC peering sess= ion. 5b) A route received with the "transit" bit set MAY be accepted by the rece= iver. 6a) A route with the "transit" bit not set (i.e. a not-transit route) MAY NOT be sent over a peering session that does not permit "transit" routes in unmodified (i.e. a peering session that demotes to not-transit). 6b) A route with the "transit" bit not set (i.e. a non-transit route) MAY ONLY be accepted over a peering session configured to send "transit" routes (i.e. an "upstream" peer). If this logic is implemented in the PROTOCOL, and outside of user configuration control (i.e. limiting user control to "not-demote" and "send-transit"), route leaks cannot happen, or at worst have a scope of the next local AS if the _receiver_ makes a configuration error. That is to say, route leaks become, at worst, non-transitive. Here's a summary of how and why: Not-transit (peer) routes can only be sent "downstream", where "downstream" can include mutual-transit links. Transit routes can be sent everywhere, but only retain their "transit" bits when _both_ the sender _and_ receiver agree that the link is a transit link. As soon as a route loses its "transit" bit, it can never regain it, whether by accident or design. Note the following: - "Transit" or "not-Transit" is applied on the sender side of peering. Default is "Transit". - "Demote" or "not-Demote" is applied on the receiver side of peering. Default is "Demote". - The originator of a route sets "Transit". - "Transit" on a sender-side really means "Do not demote this on send". - Thus, a sender with "Transit" configured, will never _promote_ a non-transit route to transit. - And thus, a receiver will automatically filter out "non-transit"-marked routes from a combined set of routes that includes "transit" and "not-transit", if only "transit" are allowed (e.g. an upstream ASN) [The original motivating discussion follows...] On Tue, Nov 1, 2011 at 9:57 AM, Stephen Kent wrote: > At 4:20 PM -0400 10/29/11, Danny McPherson wrote: > > Some comments on sidr-bgpsec-threats-00 below.. > > Most substantial of my concerns is Section 5's "Residual > Vulnerabilities", specifically: > > =A0"BGPSEC has a separate set of residual vulnerabilities: > > =A0 - BGPSEC is not able to prevent what is usually referred to as > =A0=A0=A0 route leaks, because BGP itself does not distinguish between > =A0=A0=A0 transit and non-transit ASes- This is a chicken-and-egg issue. Since there are several documents before the WG, some of which have not yet even been accepted by the WG, it is premature to say what BGPSEC does and does not do. We are (in this WG) collectively defining what BGPSEC does and does not do. The real question is, fundamentally, are there unavoidable limitations that make it impossible for BGPSEC to do particular things? > Do we really consider it acceptable that the solution and machinery > we're recommending will NOT prevent "route leaks", IMHO, "No". Frankly, I consider fixing the route leak problem non-negotiabl= e. We can and must fix it. It hasn't been fixed in BGP, because there has always been the ability to mess with transitive attributes. Without enforcement, it can't truly be fixed. Since BGPSEC is solving the attribute-tampering problem, the practical real= ities that enabled route leaks, no longer strictly exist (within a BGPSEC realm). Which means, we can stop route leaks. I argue that, because we can, now, we MUST. > Route leaks represent a violation of an ISPs local policy, i.e., the ISP > is propagating routes that it, locally, did not intend to propagate. Ther= e > is no semantic in BGP that captures this aspect of local policy. Actually, no. Route leaks represent both a violation of a BGP speaker's int= ended local policy, *and* a violation of other BGP speakers' intended policies. There is nothing that prevents the addition of this new semantic (single bit) alongside signatures, and in particular within the signed data, which unequivocably establishes this intent. By signing the intent, it becomes globally known as well as locally signifi= cant. And by being signed, it is tamper-evident. Rejecting tampered paths, or de-prefering tampered paths, eliminates route leaks. Problem solved (IMNSHO). Brian From brian.peter.dickson@gmail.com Tue Nov 1 16:00:58 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E8521F9DBC for ; Tue, 1 Nov 2011 16:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAzZlICrI5E9 for ; Tue, 1 Nov 2011 16:00:57 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id E65DD21F97C9 for ; Tue, 1 Nov 2011 16:00:56 -0700 (PDT) Received: by faas12 with SMTP id s12so8282188faa.31 for ; Tue, 01 Nov 2011 16:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=imeY5HpaUrj7wfffW7NpW6DGK7V1DC+d/8iQDRTpfn4=; b=YbBGmWwiJVsYPG0N03FdAPWgJlxyq/PbHXBtu7Xa6dFM8SN917Cqsh8Fic59ZOSpqq 0dIvv/oER67FL5x5m8/wUbZFdQxi3xGCzmjzInynFczre+FQB922R7ziNlKrSJAnYkOV w4l/ycMLGFJcl7FljhHGkAh2a1kyQv+XgBb1o= MIME-Version: 1.0 Received: by 10.223.76.27 with SMTP id a27mr3816132fak.12.1320188456066; Tue, 01 Nov 2011 16:00:56 -0700 (PDT) Received: by 10.223.54.15 with HTTP; Tue, 1 Nov 2011 16:00:56 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Nov 2011 19:00:56 -0400 Message-ID: From: Brian Dickson To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] BGPsec - proposal for threat model, protocol, requirements X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 23:00:58 -0000 Upon further consideration, in the interest of not revealing information that is currently not revealed in BGP, I'll suggest modifying my earlier proposal as follows: - the proposed flag needs to exist and be signed by the sender, but only the last instance of the flag is carried with the route. - the enforcement of not-promote still needs to be done by the protocol - the route will only have the "transit" bit on a per-route basis, of the last AS (regardless of where demotion occurred, if at all) - the receiver of a route with the "transit" bit set will generally already be aware that the receiver is providing transit service, if legitimately set Otherwise, everything else still stands to reason... Brian On Tue, Nov 1, 2011 at 6:45 PM, Brian Dickson wrote: > I have a proposal, to address the route-leak issue. It necessarily requir= es > changes to all of the following documents, if it is adopted: > - threat model > - protocol > - requirements > - NB: this proposed element does not have a corresponding value in vanill= a BGP. > - (If BGP had this already, there would not be any route leaks.) > > Here is what I propose: > Add an announced Path Attribute, "Transit", to every BGPSEC signature > block on an announced prefix. > "Transit" is a flag bit, and applies to the _announcement_ between > ASNs in the path. > Include this Transit flag in the set of things that are signed. > Make this attribute mandatory to BGPSEC, applied to every signature > block on a route. > > Every BGPSEC peering session is either Transit, or Not-Transit, from > the perspective of the local AS. > > For BGPSEC speakers A and B, all four combinations are legitimate scenari= os: > A and B are "strictly speaking, peers" - e.g. 'tier-1' networks A and B: > - A->B is "not-transit" > - B->A is "not-transit" > A provides transit to B (or vice versa; exchange labels A and B): > - A->B is "not-transit" > - B->A is "transit" > A and B provide "mutual backup transit": > - A->B is "transit" > - B->A is "transit" > > The last scenario *should* be extremely rare. The last scenario > happens to also be the default behavior > for BGP when unconstrained routing announcements exist, i.e. > inexperienced network engineers are > given "enable" and asked to "do BGP". > > Here are the specific details and semantics, that in general make "the > right thing" happen, and stop > route leaks from happening, whether by accident or design. > > 1) The "transit" bit can be demoted to "not-transit" (on received, > signed BGPSEC routes). > 2) The "transit" bit cannot be promoted from "not-transit" to > "transit" (on received, signed BGPSEC routes). > 3) Routes can be originated as "transit" or "not-transit". The > sensible default behavior is "transit". > 4) Routes that are received, under a default configuration, SHOULD be > demoted to "non-transit". > 4a) Transit ISPs MUST change the (default) configuration on their > customers' BGP sessions to not-demote their customers' routes. > 4b) Mutual-Transit arrangements MUST change the (default) > configuration to not-demote their respective routes. > 5a) A route with the "transit" bit MAY be sent over any BGPSEC peering se= ssion. > 5b) A route received with the "transit" bit set MAY be accepted by the re= ceiver. > 6a) A route with the "transit" bit not set (i.e. a not-transit route) > MAY NOT be sent over a peering session that does not permit "transit" > routes in unmodified (i.e. a peering session that demotes to > not-transit). > 6b) A route with the "transit" bit not set (i.e. a non-transit route) > MAY ONLY be accepted over a peering session configured to send > "transit" routes (i.e. an "upstream" peer). > > If this logic is implemented in the PROTOCOL, and outside of user > configuration control > (i.e. limiting user control to "not-demote" and "send-transit"), > route leaks cannot happen, or at worst have a scope > of the next local AS if the _receiver_ makes a configuration error. > > That is to say, route leaks become, at worst, non-transitive. > > Here's a summary of how and why: > Not-transit (peer) routes can only be sent "downstream", > where "downstream" can include mutual-transit links. > Transit routes can be sent everywhere, but only retain > their "transit" bits when _both_ the sender _and_ receiver agree > that the link is a transit link. > > As soon as a route loses its "transit" bit, it can never regain it, > whether by accident or design. > > Note the following: > - "Transit" or "not-Transit" is applied on the sender side of peering. > Default is "Transit". > - "Demote" or "not-Demote" is applied on the receiver side of peering. > Default is "Demote". > - The originator of a route sets "Transit". > - "Transit" on a sender-side really means "Do not demote this on send". > - Thus, a sender with "Transit" configured, will never _promote_ a > non-transit route to transit. > - And thus, a receiver will automatically filter out > "non-transit"-marked routes from a combined > =A0set of routes that includes "transit" and "not-transit", if only > "transit" are allowed (e.g. an upstream ASN) > > [The original motivating discussion follows...] > > On Tue, Nov 1, 2011 at 9:57 AM, Stephen Kent wrote: >> At 4:20 PM -0400 10/29/11, Danny McPherson wrote: >> >> Some comments on sidr-bgpsec-threats-00 below.. >> >> Most substantial of my concerns is Section 5's "Residual >> Vulnerabilities", specifically: >> >> =A0"BGPSEC has a separate set of residual vulnerabilities: >> >> =A0 - BGPSEC is not able to prevent what is usually referred to as >> =A0=A0=A0 route leaks, because BGP itself does not distinguish between >> =A0=A0=A0 transit and non-transit ASes- > > This is a chicken-and-egg issue. Since there are several documents before > the WG, some of which have not yet even been accepted by the WG, it > is premature to say what BGPSEC does and does not do. > > We are (in this WG) collectively defining what BGPSEC does and does not d= o. > The real question is, fundamentally, are there unavoidable limitations th= at > make it impossible for BGPSEC to do particular things? > >> Do we really consider it acceptable that the solution and machinery >> we're recommending will NOT prevent "route leaks", > > IMHO, "No". Frankly, I consider fixing the route leak problem non-negotia= ble. > We can and must fix it. It hasn't been fixed in BGP, because there has > always been the > ability to mess with transitive attributes. Without enforcement, it > can't truly be fixed. > > Since BGPSEC is solving the attribute-tampering problem, the practical re= alities > that enabled route leaks, no longer strictly exist (within a BGPSEC realm= ). > Which means, we can stop route leaks. > > I argue that, because we can, now, we MUST. > >> Route leaks represent a violation of an ISPs local policy, i.e., the ISP >> is propagating routes that it, locally, did not intend to propagate. The= re >> is no semantic in BGP that captures this aspect of local policy. > > Actually, no. Route leaks represent both a violation of a BGP speaker's i= ntended > local policy, *and* a violation of other BGP speakers' intended policies. > > There is nothing that prevents the addition of this new semantic > (single bit) alongside signatures, > and in particular within the signed data, which unequivocably > establishes this intent. > > By signing the intent, it becomes globally known as well as locally signi= ficant. > And by being signed, it is tamper-evident. Rejecting tampered paths, > or de-prefering > tampered paths, eliminates route leaks. > > Problem solved (IMNSHO). > > Brian > From john@jlc.net Tue Nov 1 16:04:54 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072BC21F9DDD for ; Tue, 1 Nov 2011 16:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.519 X-Spam-Level: X-Spam-Status: No, score=-106.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwcpDQ6s2xFJ for ; Tue, 1 Nov 2011 16:04:53 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3A83E21F8F0F for ; Tue, 1 Nov 2011 16:04:27 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 786F733C23; Tue, 1 Nov 2011 19:04:26 -0400 (EDT) Date: Tue, 1 Nov 2011 19:04:26 -0400 From: John Leslie To: "George, Wes" Message-ID: <20111101230426.GC1872@verdi> References: <20111031182058.24592.70473.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: "sidr@ietf.org" Subject: Re: [sidr] 4-byte vs 2 byte ASN (was re: I-D Action: draft-ietf-sidr-pfx-validate-03.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 23:04:54 -0000 George, Wes wrote: > > I'm thinking that we need a comment early in the draft stating that > for the remainder of the draft no distinction is being made between > AS_PATH and AS4_PATH, I wouldn't phrase it that way -- I'd emphasize instead that the AS Path being validated is the AS Path _after_ reconstruction using AS4_PATH in the case where routing information comes from a peer which doesn't recognize 4-byte ASNs. (It would be simply wrong to "validate" AS4_PATH in the case where you don't also do the reconstruction, or in the protocol-violating case where you receive AS4_PATH from a peer which does speak 4-byte ASNs.) > Or alternatively, specify that this validation is performed on > AS4_PATH That would also be wrong. :^( > and require support for 4893 as a prerequisite for SIDR. IMHO, support for 4-byte ASNs should be a prerequisite. Alas, this _does_ need to be stated. > If we don't explicitly require hosts that support SIDR origin > validation to support 4-byte ASN, we may also need some direction > regarding specific handling for AS23456, It would be good to add that anyway, since I contend that we can't be sure AS23456 will always be removed. -- John Leslie From terry.manderson@icann.org Tue Nov 1 18:29:09 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B900A1F0C41 for ; Tue, 1 Nov 2011 18:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZOOtFL3QIJL for ; Tue, 1 Nov 2011 18:29:09 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 43BC51F0C38 for ; Tue, 1 Nov 2011 18:29:09 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 1 Nov 2011 18:29:09 -0700 From: Terry Manderson To: Stephen Kent Date: Tue, 1 Nov 2011 18:29:06 -0700 Thread-Topic: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 Thread-Index: AcyYhBKeawFgPH9ESIiti6BbibxnvgAer0IL Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-sidr-algorithm-agility@tools.ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 01:29:09 -0000 On 31/10/11 11:59 PM, "Stephen Kent" wrote: >>=20 >> I understand why you want to, but don't come to the same conclusion as t= o >> the mechanism. >>=20 >> Is that really the IETF's job? >=20 > SIDR was tasked by the SEc ADs to develop an alg transition architecture. > The authors believe that uniform milestones are necessary as part of > a credible plan. >=20 Architecture, yes. Structured approach, yes. To both of those I agree. Having the IETF define the dates when algorithms shift. I am not convinced. >>=20 >> Call me a dirty rotten cynic but I just don't see this operational aspec= t of >> one or more running RPKI hierarchies as part of the IETF. Although you c= an >> prove me wrong, and I'll concede to an already enacted example where dat= es >> were set for some artifact. >=20 > We have to have two, parallel hierarchies to avoid a flag day. This > is not a situation where every CA can decide, locally, when to > transition, because the the alg change affect ALL RPs. We are talking years. The overlap will be significant. And I disagree - in this case every CA has to consciously decide - there may well be a situatio= n that a mid term operational impact requires an important CA in the middle o= f the chain to delay. That then renders all dates specified in any RFC next t= o meaningless. >>=20 >> I'm still not with you on this - I understand that it makes life easy to= say >> "the IETF said 12/12/2018 is D-Day, get with it" .. ... buuuutt I see th= at >> as a step beyond what the IETF should do. >=20 > If not the IETF, then whom? The IETF (via SIDR) is the author of the > CP. This is an extension of the CP, in many respects. The IETF (via SIDR) doesn't implement the hierarchy, nor operate the CAs. Perhaps the parent(s) and 'non-leaf' CAs should work on this and issue a statement of transition in following RFCXXXX (this draft). I'm reasonably sure the non-leaf CAs are capable of making noise when required ;) As an example of flag day events, even though RFC5855 ( Nameservers for IPv= 4 and IPv6 Reverse Zones ) was published as an IETF document. It was left to the various operators (root-servers, reverse-servers et al) to work on the transition. Admittedly no change was required on the user's software. The principle isn't that much different. What I do like about the document is the pre-canned phases, of what happens when, and how. This is good.. and I think that satisfies the request from the SEC ADs, but specifying the "when" in IETF - I just don't buy. Cheers Terry From randy@psg.com Tue Nov 1 20:58:41 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FAC1F0C55 for ; Tue, 1 Nov 2011 20:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWPeF20tGpbQ for ; Tue, 1 Nov 2011 20:58:41 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id EC8D71F0C43 for ; Tue, 1 Nov 2011 20:58:40 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RLRyG-000CSR-6P; Wed, 02 Nov 2011 03:58:36 +0000 Date: Wed, 02 Nov 2011 04:58:34 +0100 Message-ID: From: Randy Bush To: Brian Dickson In-Reply-To: References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 03:58:41 -0000 > I believe the concerns regarding "AS-path cheating" to attract > traffic, by using pCount=0, could be addressed with some special > handling. draft-ietf-sidr-bgpsec-ops-01 suggests a knob If it is known that a BGPsec neighbor is not a transparent route server, and the router provides a knob to disallow a received pCount (prepend count, zero for transparent route servers) of zero, that knob SHOULD be applied. randy From randy@psg.com Tue Nov 1 21:04:43 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DDB1F0C8E for ; Tue, 1 Nov 2011 21:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UN3M2KlWnI6d for ; Tue, 1 Nov 2011 21:04:43 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1875321F9EAD for ; Tue, 1 Nov 2011 21:04:24 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RLS3q-000CT5-GR; Wed, 02 Nov 2011 04:04:23 +0000 Date: Wed, 02 Nov 2011 05:04:21 +0100 Message-ID: From: Randy Bush To: Wesley George In-Reply-To: References: <20111031182058.24592.70473.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] 4-byte vs 2 byte ASN (was re: I-D Action: draft-ietf-sidr-pfx-validate-03.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 04:04:43 -0000 aven i, an old fuddy duddy, kinda assume that an AS number is two or four bytes, an ip address is ipv4 or ipv6, etc. i can understand clarifying once in a document where it is critical to do so, but would not be inclined to make it explicit everywhere AS is used or ip address is used. randy From pmohapat@cisco.com Tue Nov 1 23:10:27 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0C311E807F for ; Tue, 1 Nov 2011 23:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ags1JAhlv-id for ; Tue, 1 Nov 2011 23:10:25 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 19B2B11E80B1 for ; Tue, 1 Nov 2011 23:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pmohapat@cisco.com; l=1151; q=dns/txt; s=iport; t=1320214169; x=1321423769; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=lEJwOoZqhJKRHzOuHSPGwAkWjVBY0BZcwyw6s4oMfLY=; b=IIIlAvvnXiy/aDQ8sL/YxY+JerespgGVY79MaP6iS7AwnxexjAtQTuWO jqZfJ4x+wzj8ge+GtUKarzfR75iVbcjxXfymTfyLzl5qW1DGV2FhWQuZ4 r+rrkS/mA03rHIahZDm6UdoqBA6l+hhjHJXSjymW8QuS7s73d3QNm9BL7 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAL/dsE6rRDoG/2dsb2JhbABEqVGBBYFyAQEBAwESASUCPwULC0ZXBjWHYJZgAZ44iCdhBIgGjAuSAQ X-IronPort-AV: E=Sophos;i="4.69,442,1315180800"; d="scan'208";a="10487727" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 02 Nov 2011 06:09:29 +0000 Received: from sjc-vpn5-1887.cisco.com (sjc-vpn5-1887.cisco.com [10.21.95.95]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA269TR0021231; Wed, 2 Nov 2011 06:09:29 GMT Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Pradosh Mohapatra In-Reply-To: Date: Tue, 1 Nov 2011 23:09:36 -0700 Content-Transfer-Encoding: 7bit Message-Id: <01D94DBA-0B91-4AA8-9666-A4B22B13FE4A@cisco.com> References: <20111031182058.24592.70473.idtracker@ietfa.amsl.com> To: "George, Wes" X-Mailer: Apple Mail (2.1075.2) Cc: "sidr@ietf.org" Subject: Re: [sidr] 4-byte vs 2 byte ASN (was re: I-D Action: draft-ietf-sidr-pfx-validate-03.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 06:10:27 -0000 > Posing the question about 4-byte ASNs in my review of the BGPSec > design reqs draft yesterday makes me wonder about the same in pfx- > validate. The draft makes reference to AS_PATH in several locations. > I'm thinking that we need a comment early in the draft stating that > for the remainder of the draft no distinction is being made between > AS_PATH and AS4_PATH, and that this standard is expected to support > origin validation of both. Or alternatively, specify that this > validation is performed on AS4_PATH and require support for 4893 as > a prerequisite for SIDR. > If we don't explicitly require hosts that support SIDR origin > validation to support 4-byte ASN, we may also need some direction > regarding specific handling for AS23456, such as to always treat as > unknown since there is no way to determine validity for the > combination of a prefix and a non-unique placeholder ASN (except for > local TA), but we don't necessarily want those routes to be treated > as invalid. I think it's fair to assume that routers supporting origin validation also support 4893. - Pradosh From kent@bbn.com Wed Nov 2 01:53:34 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC3311E810F for ; Wed, 2 Nov 2011 01:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.417 X-Spam-Level: X-Spam-Status: No, score=-106.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsII+218wEgJ for ; Wed, 2 Nov 2011 01:53:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7D36F11E810B for ; Wed, 2 Nov 2011 01:53:33 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:58894 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RLWZY-000HQj-4k; Wed, 02 Nov 2011 04:53:24 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 2 Nov 2011 04:34:45 -0400 To: Terry Manderson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "draft-ietf-sidr-algorithm-agility@tools.ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 08:53:35 -0000 At 6:29 PM -0700 11/1/11, Terry Manderson wrote: >On 31/10/11 11:59 PM, "Stephen Kent" wrote: > > >>> >>> I understand why you want to, but don't come to the same conclusion as to >>> the mechanism. >>> >>> Is that really the IETF's job? >> >> SIDR was tasked by the SEc ADs to develop an alg transition architecture. >> The authors believe that uniform milestones are necessary as part of >> a credible plan. >> > >Architecture, yes. Structured approach, yes. To both of those I agree. >Having the IETF define the dates when algorithms shift. I am not convinced. An architecture that ignores the need to have a global, uniform set of milestones for transition phases is incomplete. > >> Call me a dirty rotten cynic but I just don't see this >operational aspect of > >> one or more running RPKI hierarchies as part of the IETF. Although you can >>> prove me wrong, and I'll concede to an already enacted example where dates >>> were set for some artifact. >> >> We have to have two, parallel hierarchies to avoid a flag day. This >> is not a situation where every CA can decide, locally, when to >> transition, because the the alg change affect ALL RPs. > >We are talking years. The overlap will be significant. And I disagree - in >this case every CA has to consciously decide - there may well be a situation >that a mid term operational impact requires an important CA in the middle of >the chain to delay. That then renders all dates specified in any RFC next to >meaningless. Yes, we are talking years. No, it cannot be a local, per-CA decision, because the transition affects all RPs. I anticipate that the stakeholders, CAs and RPs, will have the ability to comment on the proposed dates, and that the IETF/IESG will take into account these comments when developing the timeline. If a major problem arises that makes it infeasible for CAs to adhere t the timeline, a new RFC can be issued. > >> I'm still not with you on this - I understand that it makes life >easy to say > >> "the IETF said 12/12/2018 is D-Day, get with it" .. ... buuuutt I see that >>> as a step beyond what the IETF should do. >> >> If not the IETF, then whom? The IETF (via SIDR) is the author of the >> CP. This is an extension of the CP, in many respects. > >The IETF (via SIDR) doesn't implement the hierarchy, nor operate the CAs. agreed. >Perhaps the parent(s) and 'non-leaf' CAs should work on this and issue a >statement of transition in following RFCXXXX (this draft). I'm reasonably >sure the non-leaf CAs are capable of making noise when required ;) See comments above re setting and revising the timeline. >As an example of flag day events, even though RFC5855 ( Nameservers for IPv4 >and IPv6 Reverse Zones ) was published as an IETF document. It was left to >the various operators (root-servers, reverse-servers et al) to work on the >transition. Admittedly no change was required on the user's software. The >principle isn't that much different. I disagree. Because an alg transition does impact all RPs, there is a big difference. >What I do like about the document is the pre-canned phases, of what happens >when, and how. This is good.. and I think that satisfies the request from >the SEC ADs, but specifying the "when" in IETF - I just don't buy. So, who do you propose as alternates? Your comment above about parent(s) and "non-leaf" CAs issuing a statement encompasses IANA, the RIRs, and thousands of ISPs. When has that set of players issued a statement analogous to this? Steve From hannes@juniper.net Wed Nov 2 07:57:49 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2CA11E80B6 for ; Wed, 2 Nov 2011 07:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fr7hwHaYeNoI for ; Wed, 2 Nov 2011 07:57:48 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 04D3E11E8099 for ; Wed, 2 Nov 2011 07:57:47 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Wed, 02 Nov 2011 07:57:48 PDT Received: from hannes-755.juniper.net (172.23.7.205) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Wed, 2 Nov 2011 07:53:44 -0700 Received: by hannes-755.juniper.net (Postfix, from userid 1000) id 53CDA28CDD; Wed, 2 Nov 2011 15:53:37 +0100 (CET) Date: Wed, 2 Nov 2011 15:53:37 +0100 From: Hannes Gredler To: Pradosh Mohapatra Message-ID: <20111102145335.GA13955@juniper.net> References: <20111031182058.24592.70473.idtracker@ietfa.amsl.com> <01D94DBA-0B91-4AA8-9666-A4B22B13FE4A@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <01D94DBA-0B91-4AA8-9666-A4B22B13FE4A@cisco.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "sidr@ietf.org" Subject: Re: [sidr] 4-byte vs 2 byte ASN (was re: I-D Action: draft-ietf-sidr-pfx-validate-03.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 14:57:49 -0000 On Tue, Nov 01, 2011 at 11:09:36PM -0700, Pradosh Mohapatra wrote: | >Posing the question about 4-byte ASNs in my review of the BGPSec | >design reqs draft yesterday makes me wonder about the same in pfx- | >validate. The draft makes reference to AS_PATH in several | >locations. I'm thinking that we need a comment early in the draft | >stating that for the remainder of the draft no distinction is | >being made between AS_PATH and AS4_PATH, and that this standard is | >expected to support origin validation of both. Or alternatively, | >specify that this validation is performed on AS4_PATH and require | >support for 4893 as a prerequisite for SIDR. | >If we don't explicitly require hosts that support SIDR origin | >validation to support 4-byte ASN, we may also need some direction | >regarding specific handling for AS23456, such as to always treat | >as unknown since there is no way to determine validity for the | >combination of a prefix and a non-unique placeholder ASN (except | >for local TA), but we don't necessarily want those routes to be | >treated as invalid. | | | I think it's fair to assume that routers supporting origin | validation also support 4893. i concur; From kent@bbn.com Wed Nov 2 08:05:42 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A000C11E80B6 for ; Wed, 2 Nov 2011 08:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.33 X-Spam-Level: X-Spam-Status: No, score=-106.33 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apBJuxBC2dow for ; Wed, 2 Nov 2011 08:05:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 01D6411E8083 for ; Wed, 2 Nov 2011 08:05:41 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:38880 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RLcNj-00059F-G1; Wed, 02 Nov 2011 11:05:35 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> Date: Wed, 2 Nov 2011 11:04:53 -0400 To: Danny McPherson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 15:05:42 -0000 At 10:03 PM -0400 10/28/11, Danny McPherson wrote: >On Oct 28, 2011, at 2:40 PM, Christopher Morrow wrote: > >> Seems that the authors, at least, expect this doc to be prepared for >> WGLC, could we do that concluding 11/11/11 please? > > >I've got a couple of comments. > >Some high-level bits captured with specific comments below >include: This isn't my doc, but I will reply to a few of your points, since I've been replying to your comments on the threat model :-). >2) from a mechanics and processing perspective, this appears to >largely focus only on external BGP. It would be useful if the >requirements considered what behaviors and recommendations are >applicable to internal BGP speakers as well. The focus of BGPSEC is eBGP, because the concern is verifying the authenticity of routes arriving from other ASes. The hard problems arise for eBGP because these routes are delivered via BGP speakers in different "trust domains." iBGP integrity and authenticity can be achieved via internal security procedures and thus is not a focus of BGPSEC. >2) This document seems to allude to a solution that only protects >NLRI and AS_PATH, and ignores ORIGIN and other attributes. This >concerns me a great deal given that most (all?) path selection >today is largely based on policy derived from and applied based >upon all those other attributes. I replied to the ORIGIN attribute question in my other message. NLRI and AS_PATH are the attributes being protected both because they represent the fundamental routing data elements, and because they are attested to in the RPKI. Using the RPKI we can determine whether the origin AS is authorized to originate a route for the NLRI. We can verify whether a BGP speaker representing each AS in the AS_PATH is the entity that signed the data carried as part of an Update. We don't have analogous, authoritative data about MPLS, for example, so we can't provide the same sort of security guarantees. If the community identifies data carried in Updates that it believes should be protected, and we can agree on security semantics that are enforceable relative to the BGPSEC architecture, then we could expand protection, perhaps in a v2 of the protocol. >3) as a WG we need to agree on what constitutes a reasonable >solution for minimizing an exposure window. If we're going >to build such a heavy solution I find it hard to justify new >hardware and tons of complexity if we can't get the window to >seconds or minutes, rather than 8+ hours or more best case with >what we've seen proposed to date, and that's with periodic >updates (ala beacons) that have the scaling properties of RIP. Beacon frequency affects how responsive BGPSEC is relative to one set of attacks. A more accurate statement is that the beacon parameters that the BGPSEC design is likely to use will induce significant latency detecting those attacks. Reducing the latency would require more frequent beaconing, and that is viewed as an unacceptable tradeoff, at lest for now. The residual vulnerability due to beacon latency relates to the ability of an AS that was authorized to advertise a route, to replay the advertisement, even when it is not currently authorized to do so. This vulnerability should be viewed in the context of the inability of a BGP speaker to know whether a neighbor has failed to withdraw a route, when it has no paths for the prefix in question. An AS cannot, in general, know whether the only route for a given prefix has been withdrawn at some point upstream. This the BGP design and operational model embodies this vulnerability. Steve From kent@bbn.com Wed Nov 2 08:05:44 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CB311E80B6 for ; Wed, 2 Nov 2011 08:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.445 X-Spam-Level: X-Spam-Status: No, score=-106.445 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkluyZZaAEiZ for ; Wed, 2 Nov 2011 08:05:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6799411E8099 for ; Wed, 2 Nov 2011 08:05:42 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:38880 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RLcNl-00059F-NL; Wed, 02 Nov 2011 11:05:38 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> Date: Wed, 2 Nov 2011 10:52:58 -0400 To: danny@tcb.net From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-891876158==_ma============" Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 15:05:44 -0000 --============_-891876158==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 3:27 PM -0400 11/1/11, Danny McPherson wrote: > > Route leaks represent a violation of an ISPs local policy, i.e., the ISP >> is propagating routes that it, locally, did not intend to propagate. > >Perhaps the network operator DID fully intend to propagate ("leak") those >routes in order to hijack and MITM traffic? Any multi-homed customer can >launch such an attack today of this sort, and as a matter of fact, it >happens all the time, for benign or malicious purposes. > >To say that this is not a "semantics violation" and therefore in scope >does not mitigate the risk. How that risk can be considered as a >"Residual Risk" in a "Threat Model for BGP Path Security" document totally >escapes me? I interpret the task at hand as trying to secure BGP, not a new EGP. Since BGP semantics (and syntax) do not provide a basis for deciding when an advertisement constitutes a route leak, I think it reasonable that the BGPSEC threat model view this as out of scope. If BGP were modified to express semantics we're discussing, then it would be in scope, and I would expect BGPSEC to address it. > >> BGPSEC (or any analogous technology) can provide protection for BGP >> relative to two constraints: >> - the semantics of BGP have to align with the protection >> - the underlying PKI has to align with the protection >> >> Thus, for example, other attributes carried by BGP and for which the >> resource allocation system has no reference, cannot be protected. >> Similarly, route leaks, because they are a violation of a local policy, >> which is not expressed in BGP Update messages, cannot be addressed. > >But they are certainly still risks, whether the proposals at >hand can mitigate them or not is orthogonal. The threat model is based on using the RPKI as the starting point. I will add text that clearly articulates that. >And even policy >expressed in IRRs and via RPSL can result in controls that can >be put in place to mitigate various aspects of those risk. yes, one can use RPSL to express more info, but these are just assertions by the maintainers of RPSL objects. For some of this data, there is no basis for validating it via external, authoritative sources. That makes such data a poor basis for security controls. > I >don't understand how we can ignore this as an objective here, >and we certainly cannot discard it so casually as a trivial >residual threat. If some non-obvious or undisclosed roadmap >exists to solve this piece then I'm truly anxious to see it - >else it would seem to me secure IRRs bootstrapped by resource >certification data and perhaps even deployed to routers via some >rpki-rtr-esque protocol would provide a lot better protection >with a lot less overhead. We disagree about the advisability of relying on some types of IRR data, e.g., an assertion that AS X will advertise (not originate) routes for prefix Z. > >>"False Origination" should probably be "network operator", not > >>ISP, in particular given the subsequent definition of ISP. >> >> please explain. > >You use ISP in this draft as if they're the only ones who >may be multi-homed or trigger leaks or other functions, "network >operator" is much more broadly applicable and well beyond "ISP" >in the traditional sense. OK; I have changed all instances of ISP to network operator. > >>--- >>>The definition of "Route" seems to be missing the full set of >>>path attributes associated with the NLRI, it currently only >>>focuses on the AS_PATH attribute, and even omits the ORIGIN >>>code of the path. >> >> I think the definition does not omit the origin AS, but I will >> clarify the text. > >I'm not talking about Origin AS, I'm talking about "ORIGIN Type >Code" Path Attribute (i.e., i, e, or ?). Sorry, I misunderstood your question. Now I know the data item to which you were referring. I checked with a network operator here at the RIPE meetings, to understand how/why it is used. I now believe that the ORIGIN attribute is a poster boy for an attribute that is unsuitable for inter-AS protection. This attribute can be set to one of 3 values by an AS sending an Update. (One of these values cites EGP as the source of the data, so unless the Update has been terribly delayed, this is not a credible value :-).) The other two values are IGP and INCOMPLETE (i.e., mystery). How would an AS that sees this value externally verify that the value is accurate? I am unable to imagine how this would work. > > Our context assumes use of the RPKI, and the RPKI attests to only >> prefix and ASN holdings of entities, hence the focus on these >> attributes. For example, MPLS attributes are not supported in the >> RPKI, so they are out of scope here. > >I think the "Threat Model" document should give consideration >to Path Attributes beyond just AS_PATH, particularly because most >are used in path selection. If we think we don't need to protect >these because they are not in RPKI, then we should consider what >that means rather than assume RPKI contains the information for >all that we need to protect. Let me try again. If we can't identify a suitable, authoritative source of data that could be used to verify an assertion about an attribute in an Update, that attribute is not a candidate for inter-AS security mechanisms. > > The definition I used here has been widely used for many years >> in contexts where folks understand the importance of >> distinguishing among attacks, adversaries, and motivations. >> Unlike the RPKI focus on config errors, BGPSEC focuses on attacks. >> As noted in above, route leaks are out of scope, because they > > do not represent violations of BGP semantics, as expressed >> externally. > >If Enterprise_E is multi-homed to ISP_1 and ISP_2 and is a >transit customer of both, and then decides (or is compromised >and used to decide) that he wants to hijack traffic from ISP_1 >towards ISP_2 for Prefix_P by announcing ISP_2's Enterprise_E2 >Prefix_P to ISP_1 through Enterprise_E's local interconnect, >and "policy" makes it a more preferred path, how is this not >an attack? How does BGP indicate (i.e., where are the bits that say) that the Update sent to E is not to be propagated to another ISP? I've been told that the NO_EXPORT community does not have the right semantics, and that network operators do not pay attention to this anyway. >And it's most certainly a threat and one that some consider >out of scope at that? I presume that you mean in scope, right? >... > > >> I said "cannot" here because of the modifier "externally." To external >> observers, such behavior by an ISP may be viewed as odd behavior, but >> enough ISPs behave oddly enough to make this indistinguishable from >> an attack. > >But it "may" be externally detectable, which was my point that >you've reinforced :-) "May" is not a suitable basis for a secruity protocol :-). > >>Such guidance and implementation may be precisely what an attacker >>>was hoping to instigate, no? Further: >> >> The RPKI and BGPSEC designs place a high priority on maintaining >> the ability of ISPs to continue routing in the face of outages. Using >> cached, previously validated RPKI data is a good way to support this >> goal, in the face of outages, benign or malicious. So, I think we are >> making an appropriate decision here. An attacker can always try to >> effect DoS on targeted RPs, and has has fewer attack options when RPs >> can revert to cached data. > >While I agree, this can enable downgrade or other attacks, no? >Just like clicking on that self-signed or expired intermediate >CA certificate warning in a web browser, right? If so, the threat >model should indicate as such. I can add text to note that use of cached data enables some types of attacks resulting from use of stale data. > >>--- >>>I'm surprised I don't see anything here about timing dependencies >>>between RPKI and BGPSEC routers, and variances across a BGPSEC system >>>having considerable potential impacts. I think some discussion of >>>this is in order in a threats draft. >> >> There is no requirement that a BGPSEC router interact directly with >> the RPKI repository system. However, your question is still relevant >> if we substitute >> "local RPKI server" for "BGPSEC router." S 4.4 already deals with >> attacks against publication points, many of which are relevant to the >> timing concerns you cite above. The RPKI, is a distributed repository >> system with many maintainers. RPs ought not assume that they always >> have the very latest data from the system, and maintainers ought not >> assume that all RPs have the latest data. This issue is addressed in > > detail in the RPKI key rollover doc. > >But it's a threat and this is the threat document, right? If >we're not going to include it here we should at least reference >those sections. I can add text that notes the implications for RPs of using any distributed repository system with data supplied by object owners. > > Section 5 already addresses this, at a high level, see bold text: > > >> - the RPKI repository system may be attacked in ways that make >> its contents unavailable, or not current. It is anticipated that >> RPs will cope with this vulnerability through local caching of >> repository data, and through local settings that tolerate >> expired or stale repository data. >> >> I have changed this to say >> >> contents unavailable, not current current, or inconsistent. > >Not current == expired. I'll defer to crypto types here, but as >a first order function, I would like to see explicit text and reach >agreement that expired data should be used in the absence of current >data, and what the attack surface implications of using expired data >are. In PKIs it is always the case that, in the absence of the current CRL, use the old one. This is because, with one ugly exception, once you are revoked, you are revoked, you stay revoked. So, expired and stale are meaningful differences to us PKI experts. But, I agree that more text can be added to note the vulnerabilities associated with using stale or expired PKI data. Steve --============_-891876158==_ma============ Content-Type: text/html; charset="us-ascii" Re: [sidr] BGPSEC Threat Model ID
At 3:27 PM -0400 11/1/11, Danny McPherson wrote:
> Route leaks represent a violation of an ISPs local policy, i.e., the ISP
> is propagating routes that it, locally, did not intend to propagate.

Perhaps the network operator DID fully intend to propagate ("leak") those
routes in order to hijack and MITM traffic?  Any multi-homed customer can
launch such an attack today of this sort, and as a matter of fact, it
happens all the time, for benign or malicious purposes.

To say that this is not a "semantics violation" and therefore in scope
does not mitigate the risk.  How that risk can be considered as a
"Residual Risk" in a "Threat Model for BGP Path Security" document totally
escapes me?

I interpret the task at hand as trying to secure BGP, not a new EGP. Since BGP semantics (and syntax) do not provide a basis for deciding when an advertisement constitutes a route leak, I think it reasonable that the BGPSEC threat model view this as out of scope. If BGP were modified to express semantics we're discussing, then it would be in scope, and I would expect BGPSEC to address it.


> BGPSEC (or any analogous technology) can provide protection for BGP
> relative to two constraints:
>    - the semantics of BGP have to align with the protection
>       - the underlying PKI has to align with the protection
>
> Thus, for example, other attributes carried by BGP and for which the
> resource allocation system has no reference, cannot be protected.
> Similarly, route leaks, because they are a violation of a local policy,
> which is not expressed in BGP Update messages, cannot be addressed.

But they are certainly still risks, whether the proposals at
hand can mitigate them or not is orthogonal.

The threat model is based on using the RPKI as the starting point.
I will add text that clearly articulates that.
And even policy
expressed in IRRs and via RPSL can result in controls that can
be put in place to mitigate various aspects of those risk.

yes, one can use RPSL to express more info, but these are just assertions by the
maintainers of RPSL objects. For some of this data, there is no basis for validating it via external, authoritative sources. That makes such data a poor
basis for security controls.

  I
don't understand how we can ignore this as an objective here,
and we certainly cannot discard it so casually as a trivial
residual threat.  If some non-obvious or undisclosed roadmap
exists to solve this piece then I'm truly anxious to see it -
else it would seem to me secure IRRs bootstrapped by resource
certification data and perhaps even deployed to routers via some
rpki-rtr-esque protocol would provide a lot better protection
with a lot less overhead.

We disagree about the advisability of relying on some types of IRR data, e.g., an assertion that AS X will advertise (not originate) routes for prefix Z.

>>"False Origination" should probably be "network operator", not
>>ISP, in particular given the subsequent definition of ISP.
>
> please explain.

You use ISP in this draft as if they're the only ones who
may be multi-homed or trigger leaks or other functions, "network
operator" is much more broadly applicable and well beyond "ISP"
in the traditional sense.

OK; I have changed all instances of ISP to network operator.

>>---
>>The definition of "Route" seems to be missing the full set of
>>path attributes associated with the NLRI, it currently only
>>focuses on the AS_PATH attribute, and even omits the ORIGIN
>>code of the path.
>
> I think the definition does not omit the origin AS, but I will
> clarify the text.
I'm not talking about Origin AS, I'm talking about "ORIGIN Type
Code" Path Attribute (i.e., i, e, or ?).

Sorry, I misunderstood your question. Now I know the data item to which you were referring. I checked with a network operator here at the RIPE meetings, to understand how/why it is used.  I now believe that the ORIGIN attribute is a poster boy for an attribute that is unsuitable for inter-AS protection. This attribute can be set to one of 3 values by an AS sending an Update. (One of these values cites EGP as the source of the data, so unless the Update has been terribly delayed, this is not a credible value :-).)  The other two values are IGP and INCOMPLETE (i.e., mystery). How would an AS that sees this value externally verify that the value is accurate? I am unable to imagine how this would work.

> Our context assumes use of the RPKI, and the RPKI attests to only
> prefix and ASN holdings of entities, hence the focus on these
> attributes. For example, MPLS attributes are not supported in the
> RPKI, so they are out of scope here.

I think the "Threat Model" document should give consideration
to Path Attributes beyond just AS_PATH, particularly because most
are used in path selection.  If we think we don't need to protect
these because they are not in RPKI, then we should consider what
that means rather than assume RPKI contains the information for
all that we need to protect.

Let me try again. If we can't identify a suitable, authoritative source of data that could be used to verify an assertion about an attribute in an Update, that attribute is not a candidate for inter-AS security mechanisms.

> The definition I used here has been widely used for many years
> in contexts where folks understand the importance of
> distinguishing among attacks,  adversaries, and motivations.
> Unlike the RPKI focus on config errors, BGPSEC focuses on attacks.
> As noted in above, route leaks are out of scope, because they
> do not represent violations of BGP semantics, as expressed
> externally.

If Enterprise_E is multi-homed to ISP_1 and ISP_2 and is a
transit customer of both, and then decides (or is compromised
and used to decide) that he wants to hijack traffic from ISP_1
towards ISP_2 for Prefix_P by announcing ISP_2's Enterprise_E2
Prefix_P to ISP_1 through Enterprise_E's local interconnect,
and "policy" makes it a more preferred path, how is this not
an attack?

How does BGP indicate (i.e., where are the bits that say) that the Update sent to E is not to be propagated to another ISP?  I've been told that the NO_EXPORT community does not have the right semantics, and that network operators do not pay attention to this anyway.

And it's most certainly a threat and one that some consider
out of scope at that?

I presume that you mean in scope, right?
...
>
> I said "cannot" here because of the modifier "externally." To external
> observers, such behavior by an ISP may be viewed as odd behavior, but
> enough ISPs behave oddly enough to make this indistinguishable from
> an attack.

But it "may" be externally detectable, which was my point that
you've reinforced :-)

"May" is not a suitable basis for a secruity protocol :-).

>>Such guidance and implementation may be precisely what an attacker
>>was hoping to instigate, no?  Further:
>
> The RPKI and BGPSEC designs place a high priority on maintaining
> the ability of ISPs to continue routing in the face of outages. Using
> cached, previously validated RPKI data is a good way to support this
> goal, in the face of outages, benign or malicious. So, I think we are
> making an appropriate decision here. An attacker can always try to
> effect DoS on targeted RPs, and has has fewer attack options when RPs
> can revert to cached data.

While I agree, this can enable downgrade or other attacks, no?
Just like clicking on that self-signed or expired intermediate
CA certificate warning in a web browser, right?  If so, the threat
model should indicate as such.

I can add text to note that use of cached data enables some types of attacks resulting from use of stale data.


>>---
>>I'm surprised I don't see anything here about timing dependencies
>>between RPKI and BGPSEC routers, and variances across a BGPSEC system
>>having considerable potential impacts.  I think some discussion of
>>this is in order in a threats draft.
>
> There is no requirement that a BGPSEC router interact directly with
> the RPKI repository system. However, your question is still relevant
> if we substitute
> "local RPKI server" for "BGPSEC router." S 4.4 already deals with
> attacks against publication points, many of which are relevant to the
> timing concerns you cite above. The RPKI, is a distributed repository
> system with many maintainers. RPs ought not assume that they always
> have the very latest data from the system, and maintainers ought not
> assume that all RPs have the latest data.  This issue is addressed in
> detail in the RPKI key rollover doc.

But it's a threat and this is the threat document, right?  If
we're not going to include it here we should at least reference
those sections.

I can add text that notes the implications for RPs of using any distributed
repository system with data supplied by object owners.

> Section 5 already addresses this, at a high level, see bold text:
>
>      - the RPKI repository system may be attacked in ways that make
>          its contents unavailable, or not current. It is anticipated that
>          RPs will cope with this vulnerability through local caching of
>          repository data, and through local settings that tolerate
>          expired or stale repository data.
>
> I have changed this to say
>
>       contents unavailable, not current current, or inconsistent.

Not current == expired.  I'll defer to crypto types here, but as
a first order function, I would like to see explicit text and reach
agreement that expired data should be used in the absence of current
data, and what the attack surface implications of using expired data
are.

In PKIs it is always the case that, in the absence of the current CRL, use the old one. This is because, with one ugly exception, once you are revoked, you are revoked, you stay revoked. So, expired and stale are meaningful differences to us PKI experts. But, I agree that more text can be added to note the vulnerabilities associated with using stale or expired PKI data.

Steve
--============_-891876158==_ma============-- From brian.peter.dickson@gmail.com Wed Nov 2 09:08:08 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D039F1F0CBF for ; Wed, 2 Nov 2011 09:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUnwzqi9B-+5 for ; Wed, 2 Nov 2011 09:08:08 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 997661F0CAE for ; Wed, 2 Nov 2011 09:08:07 -0700 (PDT) Received: by faas12 with SMTP id s12so708259faa.31 for ; Wed, 02 Nov 2011 09:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=a1JWPcabZEhYB01bxeH9v0PoKG37TkTcfYmec/J8ssg=; b=RcuofKD4LUknPYYn0GnTB3KGk7uDCJ++H2UxYf8aZNGzq7OvUc0qlIf7tAIvx97Hrx 7KHqq191xfldXNE1RMWhddc4/0Nof0H01IvQCmuoJVa39W/LFZNrYipGFUkYB+1iSqVB YaZsm3nhqBb/IaFqhSWoAsQns9SD2+siWBtSQ= MIME-Version: 1.0 Received: by 10.223.76.27 with SMTP id a27mr9388572fak.12.1320250085340; Wed, 02 Nov 2011 09:08:05 -0700 (PDT) Received: by 10.223.54.15 with HTTP; Wed, 2 Nov 2011 09:08:05 -0700 (PDT) In-Reply-To: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> Date: Wed, 2 Nov 2011 12:08:05 -0400 Message-ID: From: Brian Dickson To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 16:08:08 -0000 On Wed, Nov 2, 2011 at 10:52 AM, Stephen Kent wrote: > At 3:27 PM -0400 11/1/11, Danny McPherson wrote: > >> Route leaks represent a violation of an ISPs local policy, i.e., the ISP >> is propagating routes that it, locally, did not intend to propagate. > > Perhaps the network operator DID fully intend to propagate ("leak") those > routes in order to hijack and MITM traffic?=A0 Any multi-homed customer c= an > launch such an attack today of this sort, and as a matter of fact, it > happens all the time, for benign or malicious purposes. > > To say that this is not a "semantics violation" and therefore in scope > does not mitigate the risk.=A0 How that risk can be considered as a > "Residual Risk" in a "Threat Model for BGP Path Security" document totall= y > > escapes me? > > I interpret the task at hand as trying to secure BGP, not a new EGP. Sinc= e > BGP semantics (and syntax) do not provide a basis for deciding when an > advertisement constitutes a route leak, I think it reasonable that the > BGPSEC threat model view this as out of scope. If BGP were modified to > express semantics we're discussing, then it would be in scope, and I woul= d > expect BGPSEC to address it. BGPSEC is an _extension_ to BGP. (This is according to the WG Charter.) Adding ways of identifying updates as "bad", whether because of failure to authenticate, or because of authenticated data which indicates a semantic violation, is in-charter. Blocking updates does not fundamentally change the BGP path selection proce= ss. Thus, it isn't more than an enforced filtering methodology. It fits squarely within the model proposed by BGPSEC. If there is a need to address _malicious_ route leaks, and it is not possible to address without securing the necessary added semantic elements, then clearly those = added elements can't and won't be done by the IDR WG, since securing those elemen= ts would be the responsibility of SIDR. Put another way - adding elements to BGP to address accidental route leaks will do nothing to address malicious route leaks. On the other hand, anything which addresses malicious route leaks, by definition, will also address accidental route leaks. Malicious route leaks and accidental route leaks are two of the biggest threats to BGP. Having two solutions, one done by IDR and another by SIDR, is clearly redun= dant, since the SIDR solution would make the IDR solution moot. Thus, it make the most sense to include the solution to malicious route leaks in SIDR's mandate. If need be, I request the WG chairs expressly poll the WG on this issue. I suggest that the issue remain in-charter for some period of time, until a solution to the problem is presented, at which time it be included in the main protocol document for BGPSEC, at which time it become mandatory. (BTW - I have already given a preliminary proposal, which is not an I-D yet, and which needs some work. But, this establishes the feasibility of achieving the semantics needed to mitigate the risk of route leaks.) > Sorry, I misunderstood your question. Now I know the data item to which y= ou > were referring. I checked with a network operator here at the RIPE meetin= gs, > to understand how/why it is used.=A0 I now believe that the ORIGIN attrib= ute > is a poster boy for an attribute that is unsuitable for inter-AS protecti= on. > This attribute can be set to one of 3 values by an AS sending an Update. > (One of these values cites EGP as the source of the data, so unless the > Update has been terribly delayed, this is not a credible value :-).)=A0 T= he > other two values are IGP and INCOMPLETE (i.e., mystery). How would an AS > that sees this value externally verify that the value is accurate? I am > unable to imagine how this would work. > >> Our context assumes use of the RPKI, and the RPKI attests to only >> prefix and ASN holdings of entities, hence the focus on these >> attributes. For example, MPLS attributes are not supported in the >> RPKI, so they are out of scope here. > > I think the "Threat Model" document should give consideration > to Path Attributes beyond just AS_PATH, particularly because most > are used in path selection.=A0 If we think we don't need to protect > these because they are not in RPKI, then we should consider what > that means rather than assume RPKI contains the information for > all that we need to protect. > > Let me try again. If we can't identify a suitable, authoritative source o= f > data that could be used to verify an assertion about an attribute in an > Update, that attribute is not a candidate for inter-AS security mechanism= s. Here's the thing: (1) RPKI authenticates the Originator. (2) The Originator signs "stuff" (2a) "stuff" MUST include all the things from RPKI. (3) Every additional AS in the path adds itself and signs the result. (4) "Stuff" can include additional elements in addition to the things already identified in the -00 version of the protocol document. (4a) The signature allows the receiver to validate that it was sent by the Originator. The RPKI assures that the Originator is allowed to originate the Update. (4b) It follows that there is no reason not to trust all Transitive values set by Originator, and Signed by the Originator (4c) It also follows that Non-Transitive values could be set by one's Neighbor AS, signed by that AS, and have those values Secured. (5) If any BGP path attribute used in Path Selection is not signed, then BGPSEC has failed to meet its charter requirements. > If Enterprise_E is multi-homed to ISP_1 and ISP_2 and is a > transit customer of both, and then decides (or is compromised > and used to decide) that he wants to hijack traffic from ISP_1 > > towards ISP_2 for Prefix_P by announcing ISP_2's Enterprise_E2 > Prefix_P to ISP_1 through Enterprise_E's local interconnect, > and "policy" makes it a more preferred path, how is this not > > an attack? > > How does BGP indicate (i.e., where are the bits that say) that the Update > sent to E is not to be propagated to another ISP?=A0 I've been told that = the > NO_EXPORT community does not have the right semantics, and that network > operators do not pay attention to this anyway. > > And it's most certainly a threat and one that some consider > out of scope at that? > > I presume that you mean in scope, right? I believe what Danny was saying is, "some consider this out of scope", where "some" means at a minimum the authors of the Threat document, and that since it is a threat, it really should be *in* scope. Consider this a +1 on this as being in scope of the Threat document, regard= less of whether or not it should be in-scope for the protocol itself. Brian From russw@riw.us Wed Nov 2 09:32:53 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5BD21F9E30 for ; Wed, 2 Nov 2011 09:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LN-CBDY5Zd+v for ; Wed, 2 Nov 2011 09:32:52 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 7030521F9E2D for ; Wed, 2 Nov 2011 09:32:52 -0700 (PDT) Received: from rtp-isp-nat1.cisco.com ([64.102.254.33]:51423 helo=rtp-russwh-8913.cisco.com) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RLdkA-0006cC-PR for sidr@ietf.org; Wed, 02 Nov 2011 12:32:51 -0400 Message-ID: <4EB170AD.1030302@riw.us> Date: Wed, 02 Nov 2011 12:32:45 -0400 From: Russ White User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sidr@ietf.org References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 16:32:53 -0000 > (4b) It follows that there is no reason not to trust all Transitive > values set by Originator, and Signed by the Originator It does not follow. Policy is per AS, not per route or destination. > (4c) It also follows that Non-Transitive values could be set by one's > Neighbor AS, signed by that AS, and have those values Secured. Can you define "secure" here? > (5) If any BGP path attribute used in Path Selection is not signed, > then BGPSEC has failed to meet its charter requirements. Then MED and Local Pref must also be signed, along with a number of communities, and even the next hop. >> How does BGP indicate (i.e., where are the bits that say) that the Update >> sent to E is not to be propagated to another ISP? I've been told that the >> NO_EXPORT community does not have the right semantics, and that network >> operators do not pay attention to this anyway. >> >> And it's most certainly a threat and one that some consider >> out of scope at that? >> >> I presume that you mean in scope, right? > > I believe what Danny was saying is, "some consider this out of scope", > where "some" means at a minimum the authors of the Threat document, > and that since it is a threat, it really should be *in* scope. Maybe there's a reason for this particular capability not existing within BGP. Perhaps it is because it's always been recognized that transmitting reachability is routing, but failing to transmit reachability that exists because you don't want someone else to use it, or --even more-- asking someone you send reachability information to not to forward that reachability information --is a matter of policy. The failure to define and separate policy from routing has caused a great deal of confusion within the BGP security space over the years. Russ From kent@bbn.com Wed Nov 2 09:36:13 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F75011E80AE for ; Wed, 2 Nov 2011 09:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.463 X-Spam-Level: X-Spam-Status: No, score=-106.463 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKg0d-eCfwvo for ; Wed, 2 Nov 2011 09:36:12 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id ECB8111E8090 for ; Wed, 2 Nov 2011 09:36:11 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:46117 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RLdnO-000MCL-0y; Wed, 02 Nov 2011 12:36:10 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> Date: Wed, 2 Nov 2011 12:35:42 -0400 To: Brian Dickson From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-891870727==_ma============" Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 16:36:13 -0000 --============_-891870727==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 12:08 PM -0400 11/2/11, Brian Dickson wrote: >... > >BGPSEC is an _extension_ to BGP. (This is according to the WG Charter.) >Adding ways of identifying updates as "bad", whether because of >failure to authenticate, >or because of authenticated data which indicates a semantic violation, >is in-charter. >Blocking updates does not fundamentally change the BGP path selection process. >Thus, it isn't more than an enforced filtering methodology. It fits >squarely within the >model proposed by BGPSEC. Dropping an update because it fails BGPSEC validation is certainly in scope, and it is consistent with the BGP model, which allows any AS to drop any update for any reason. >If there is a need to address _malicious_ route leaks, and it is not >possible to address >without securing the necessary added semantic elements, then clearly >those added >elements can't and won't be done by the IDR WG, since securing those elements >would be the responsibility of SIDR. logical, and likely to be true :-). >Put another way - adding elements to BGP to address accidental route >leaks will do >nothing to address malicious route leaks. I don't agree that this follows, but it might be true anyway. >On the other hand, anything which addresses malicious route leaks, by >definition, >will also address accidental route leaks. probably. >Malicious route leaks and accidental route leaks are two of the >biggest threats to BGP. >Having two solutions, one done by IDR and another by SIDR, is >clearly redundant, >since the SIDR solution would make the IDR solution moot. I doubt that we will have two solutions, so I will not worry about this. >Thus, it make the most sense to include the solution to malicious >route leaks in SIDR's mandate. that does not follow. In addition to the charter question (for which I think there is a clear, out-of-scope answer) the other major issue is whether a solution to route leaks is consistent with the basic BGP model. if so, then I suspect that IDR will be happy to have SIDR proceed with such a solution, under a revised, extended charter. If not, then IDR could rightfully object that our extensions are inappropriate. >If need be, I request the WG chairs expressly poll the WG on this issue. > >I suggest that the issue remain in-charter for some period of time, >until a solution to the problem is presented, >at which time it be included in the main protocol document for BGPSEC, >at which time it become mandatory. The SIDR charter is very brief and it lays out some clear requirements which I cite below. These do not extend to route leaks. >(BTW - I have already given a preliminary proposal, which is not an >I-D yet, and which needs some work. >But, this establishes the feasibility of achieving the semantics >needed to mitigate the risk of route leaks.) I've been busy replying to Danny's messages, so I have not looked at your proposal. >... > >Here's the thing: >(1) RPKI authenticates the Originator. >(2) The Originator signs "stuff" carefully restricted stuff. >(2a) "stuff" MUST include all the things from RPKI. not really. look at the BGPSEC protocol sig block. >(3) Every additional AS in the path adds itself and signs the result. >(4) "Stuff" can include additional elements in addition to the things >already identified in the -00 version of the protocol document. it could, if appropriate. >(4a) The signature allows the receiver to validate that it was sent by >the Originator. The RPKI assures that the Originator is allowed to >originate the Update. and the sig is matched against RPKI data to verify that the BGP speaker that signed the update did so on behalf of an ASN that the speaker is authorized to represent. when the data covered by the sig is AS path info, the semantics of the RPKI certs and ROAs match the signed data. when we consider adding other data under a sig, we have to ask whether it is sufficient to know that a specific speaker signed the data. As an example, if one receives an S/MIME message, and the sig validates, that does NOT mean that you can trust he FROM field in the message header! >(4b) It follows that there is no reason not to trust all Transitive >values set by Originator, and Signed by the Originator disagree, for the reasons alluded to above. >(4c) It also follows that Non-Transitive values could be set by one's >Neighbor AS, signed by that AS, and have those values Secured. huh? >(5) If any BGP path attribute used in Path Selection is not signed, >then BGPSEC has failed to meet its charter requirements. Look at the charter again. In particular it begins by saying: The purpose of the SIDR working group is to reduce vulnerabilities in the inter-domain routing system. The two vulnerabilities that will be addressed are: * Is an Autonomous System (AS) authorized to originate an IP prefix * Is the AS-Path represented in the route the same as the path through which the NLRI traveled The charter does NOT say that other path attributes need to be secured. Steve --============_-891870727==_ma============ Content-Type: text/html; charset="us-ascii" Re: [sidr] BGPSEC Threat Model ID
At 12:08 PM -0400 11/2/11, Brian Dickson wrote:
...

BGPSEC is an _extension_ to BGP. (This is according to the WG Charter.)
Adding ways of identifying updates as "bad", whether because of
failure to authenticate,
or because of authenticated data which indicates a semantic violation,
is in-charter.
Blocking updates does not fundamentally change the BGP path selection process.
Thus, it isn't more than an enforced filtering methodology. It fits
squarely within the
model proposed by BGPSEC.

Dropping an update because it fails BGPSEC validation is certainly in scope,
and it is consistent with the BGP model, which allows any AS to drop any update for any reason.

If there is a need to address _malicious_ route leaks, and it is not
possible to address
without securing the necessary added semantic elements, then clearly those added
elements can't and won't be done by the IDR WG, since securing those elements
would be the responsibility of SIDR.

logical, and likely to be true :-).

Put another way - adding elements to BGP to address accidental route
leaks will do
nothing to address malicious route leaks.

I don't agree that this follows, but it might be true anyway.

On the other hand, anything which addresses malicious route leaks, by
definition,
will also address accidental route leaks.

probably.
Malicious route leaks and accidental route leaks are two of the
biggest threats to BGP.
Having two solutions, one done by IDR and another by SIDR, is clearly redundant,
since the SIDR solution would make the IDR solution moot.

I doubt that we will have two solutions, so I will not worry about this.

Thus, it make the most sense to include the solution to malicious
route leaks in SIDR's mandate.

that does not follow. In addition to the charter question (for which I think there is a clear, out-of-scope answer) the other major issue is whether a solution to route leaks is consistent with the basic BGP model. if so, then I suspect that IDR will be happy to have SIDR proceed with such a solution, under a revised, extended charter. If not, then IDR could rightfully object that our extensions are inappropriate.

If need be, I request the WG chairs expressly poll the WG on this issue.

I suggest that the issue remain in-charter for some period of time,
until a solution to the problem is presented,
at which time it be included in the main protocol document for BGPSEC,
at which time it become mandatory.

The SIDR charter is very brief and it lays out some clear requirements which I cite below. These do not extend to route leaks.

(BTW - I have already given a preliminary proposal, which is not an
I-D yet, and which needs some work.
But, this establishes the feasibility of achieving the semantics
needed to mitigate the risk of route leaks.)

I've been busy replying to Danny's messages, so I have not looked at your
proposal.

...

Here's the thing:
(1) RPKI authenticates the Originator.
(2) The Originator signs "stuff"

carefully restricted stuff.

(2a) "stuff" MUST include all the things from RPKI.

not really. look at the BGPSEC protocol sig block.

(3) Every additional AS in the path adds itself and signs the result.
(4) "Stuff" can include additional elements in addition to the things
already identified in the -00 version of the protocol document.

it could, if appropriate.
(4a) The signature allows the receiver to validate that it was sent by
the Originator. The RPKI assures that the Originator is allowed to
originate the Update.

and the sig is matched against RPKI data to verify that the BGP speaker that signed the update did so on behalf of an ASN that the speaker is authorized to represent. when the data covered by the sig is AS path info, the semantics of the RPKI certs and ROAs match the signed data. when we consider adding other data under a sig, we have to ask whether it is sufficient to know that a specific speaker signed the data. As an example, if one receives an S/MIME message, and the sig validates, that does NOT mean that you can trust he FROM field in the message header!

(4b) It follows that there is no reason not to trust all Transitive
values set by Originator, and Signed by the Originator

disagree, for the reasons alluded to above.

(4c) It also follows that Non-Transitive values could be set by one's
Neighbor AS, signed by that AS, and have those values Secured.

huh?
(5) If any BGP path attribute used in Path Selection is not signed,
then BGPSEC has failed to meet its charter requirements.

Look at the charter again.  In particular it begins by saying:

The purpose of the SIDR working group is to reduce vulnerabilities in
the inter-domain routing system. The two vulnerabilities that will be
addressed are:

* Is an Autonomous System (AS) authorized to originate an IP prefix
* Is the AS-Path represented in the route the same as the path through
which the NLRI traveled

The charter does NOT say that other path attributes need to be secured.

Steve
--============_-891870727==_ma============-- From wesley.george@twcable.com Wed Nov 2 09:38:39 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E33411E8090 for ; Wed, 2 Nov 2011 09:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.295 X-Spam-Level: X-Spam-Status: No, score=-0.295 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irl4qtcp0Iun for ; Wed, 2 Nov 2011 09:38:38 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4B511E80C1 for ; Wed, 2 Nov 2011 09:38:37 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,443,1315195200"; d="scan'208";a="277382845" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 02 Nov 2011 12:34:21 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Wed, 2 Nov 2011 12:38:36 -0400 From: "George, Wes" To: Randy Bush Date: Wed, 2 Nov 2011 12:38:35 -0400 Thread-Topic: [sidr] 4-byte vs 2 byte ASN (was re: I-D Action: draft-ietf-sidr-pfx-validate-03.txt) Thread-Index: AcyZFI4qQ/iuoR5/RLKr+JxDf05Y5gASCZ5g Message-ID: References: <20111031182058.24592.70473.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] 4-byte vs 2 byte ASN (was re: I-D Action: draft-ietf-sidr-pfx-validate-03.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 16:38:39 -0000 > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > > aven i, an old fuddy duddy, kinda assume that an AS number is two or > four bytes, an ip address is ipv4 or ipv6, etc. i can understand > clarifying once in a document where it is critical to do so, but would > not be inclined to make it explicit everywhere AS is used or ip address > is used. > > randy [WEG] And I agree with the notion that unless specified as one or the other= , it means the combination. However, especially in documents dealing with t= he mechanics of wrangling the bits on the router, that is not an implementa= tion detail I want to leave purely to assumption/interpretation. Doesn't ha= ve to be stated and restated ad infinitum, I simply mention the other docs = because I wasn't 100% certain where it made the most sense to cover it. Based on the comments thus far, sounds like the questions are: Q1) is RFC4893 support a prerequisite for those routers supporting SIDR Ori= gin and Path validation A: Yes. I believe that this needs to be explicitly documented, where is the most ap= propriate location? Q2) Do we need to incorporate something like: "MUST validate the AS Path _a= fter_ reconstruction using AS4_PATH in the case where routing information c= omes from a peer which doesn't recognize 4-byte ASNs" as John suggested? Q3) do we need some sort of language recommending a method to handle AS2345= 6 as an origin (or in a path in the case of BGPSec), especially if it does = not coincide with valid AS4_PATH info? Technically if we're saying 4893 is a prereq, this shouldn't happen, but I = could see it as a possible attack vector if we don't explicitly cover it. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From brian.peter.dickson@gmail.com Wed Nov 2 10:12:23 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B2A21F9F0B for ; Wed, 2 Nov 2011 10:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iusMi3j7nYDq for ; Wed, 2 Nov 2011 10:12:22 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 343A621F9F0A for ; Wed, 2 Nov 2011 10:12:22 -0700 (PDT) Received: by faas12 with SMTP id s12so781851faa.31 for ; Wed, 02 Nov 2011 10:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=81WTqZ1vMZlR5tzEbILn9SI5PGKYJTbI8TcO8Pi+zaI=; b=JaHCYDnq94gjQQ0bRjj9cW3Q+fv58w0dS/cKf/MtA44VxRoIlPydZ05DvxKhZd/rR0 9/hMJlgPb1qurCeD0TvafRXNavqQWfQc6XEq9mxzULoPZV0iIJc14FxsKaqHwy2VZFnh YeLDpXdHXbgq0eZt0WRhQEV/Elg1K2aJNm9Sk= MIME-Version: 1.0 Received: by 10.223.61.72 with SMTP id s8mr3187186fah.27.1320253720826; Wed, 02 Nov 2011 10:08:40 -0700 (PDT) Received: by 10.223.54.15 with HTTP; Wed, 2 Nov 2011 10:08:40 -0700 (PDT) In-Reply-To: <4EB170AD.1030302@riw.us> References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <4EB170AD.1030302@riw.us> Date: Wed, 2 Nov 2011 13:08:40 -0400 Message-ID: From: Brian Dickson To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 17:12:23 -0000 On Wed, Nov 2, 2011 at 12:32 PM, Russ White wrote: > >> (4b) It follows that there is no reason not to trust all Transitive >> values set by Originator, and Signed by the Originator > > It does not follow. Policy is per AS, not per route or destination. Trust policy is necessarily per AS. Routing policy is de facto per route. Each prefix will be independently signed, so it follows that including othe= r parameters in the signature is not unreasonable. It does not change the number of signatures needed, only the size of the blob being signed, and generally speaking marginally. >> (4c) It also follows that Non-Transitive values could be set by one's >> Neighbor AS, signed by that AS, and have those values Secured. > > Can you define "secure" here? Signed. >> (5) If any BGP path attribute used in Path Selection is not signed, >> then BGPSEC has failed to meet its charter requirements. > > Then MED and Local Pref must also be signed, along with a number of > communities, and even the next hop. Yes. >>> How does BGP indicate (i.e., where are the bits that say) that the Upda= te >>> sent to E is not to be propagated to another ISP? =A0I've been told tha= t the >>> NO_EXPORT community does not have the right semantics, and that network >>> operators do not pay attention to this anyway. >>> >>> And it's most certainly a threat and one that some consider >>> out of scope at that? >>> >>> I presume that you mean in scope, right? >> >> I believe what Danny was saying is, "some consider this out of scope", >> where "some" means at a minimum the authors of the Threat document, >> and that since it is a threat, it really should be *in* scope. > > Maybe there's a reason for this particular capability not existing > within BGP. Perhaps it is because it's always been recognized that > transmitting reachability is routing, but failing to transmit > reachability that exists because you don't want someone else to use it, > or --even more-- asking someone you send reachability information to not > to forward that reachability information --is a matter of policy. > > The failure to define and separate policy from routing has caused a > great deal of confusion within the BGP security space over the years. Correct. And given that there exist malicious use cases for violating impli= cit policy, it makes sense that it be addressed in conjunction with BGPSEC. The particulars on how to implement marking and enforcement are important, and there are pros and cons to the variety of ways of doing this. However, the high-level semantics can be captured easily, on a per-prefix, per-peering basis: "You're not my transit provider" vs "Please be my transit provider" Perhaps this would best be done as a BGP Option negotiated on a peering session, in each direction: "Transit Requested" / "Transit Offered" (In the oddball case of mutual transit, both flags would be set in both directions). Even if there isn't enforcement of behavior per se, the ability to view the asserted policy on a per-AS-hop basis allows for local receiver filtering based on the presence/absence of such a flag bit anywhere in the path, per-prefix. Having the bit signed by the Sender (as part of the signed data, that is) means that anyone wishing to honor the sender's intent, is able to do so automatically. (There are two options - enforce behavior per AS hop within the protocol, or expose the per-hop values. The latter is more robust, protecting against malicious implementations as well as poor configurations.) Brian From russw@riw.us Wed Nov 2 10:41:53 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1046B11E814D for ; Wed, 2 Nov 2011 10:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.692 X-Spam-Level: X-Spam-Status: No, score=-1.692 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, SARE_UNSUB22=0.948] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+t5EiS9mLyb for ; Wed, 2 Nov 2011 10:41:52 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 8622A11E8149 for ; Wed, 2 Nov 2011 10:41:52 -0700 (PDT) Received: from rtp-isp-nat1.cisco.com ([64.102.254.33]:50908 helo=rtp-russwh-8913.cisco.com) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RLeox-0002DX-1T; Wed, 02 Nov 2011 13:41:51 -0400 Message-ID: <4EB180DD.5010401@riw.us> Date: Wed, 02 Nov 2011 13:41:49 -0400 From: Russ White User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Brian Dickson References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <4EB170AD.1030302@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: sidr@ietf.org Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 17:41:53 -0000 > Signed. I wonder --if I sign my door knob, does that make it secure? Cryptographic signatures are not security. In fact, for all our wailing about "obscurity is not security," cryptography is just a more sophisticated form of obscurity. Somewhere along the way we've lost sight of the original meaning of that phrase, and the original goals of security. >> The failure to define and separate policy from routing has caused a >> great deal of confusion within the BGP security space over the years. > > Correct. And given that there exist malicious use cases for violating implicit > policy, it makes sense that it be addressed in conjunction with BGPSEC. There are several problems here. 1. Most providers apparently want to enforce policy without telling anyone what their policy actually is. That this is a logical contradiction doesn't seem to disturb anyone. 2. You can't "enforce" your policy --all you can do is signal to someone else what that policy is, and ask them nicely to enforce it for you. 2a. If you have a business relationship with this other party, then you already have an enforcement mechanism at hand --signatures and other sorts of things won't provide anything additional. 2b. If you don't have a business relationship with this other party, then there's no point in asking, because they're going to do what's best for them, not for you. There's some sort of dream world where you can not tell anyone what your policies are, and people you don't have a business relationship with will somehow enforce those policies (that they don't know about, because you refuse to tell them) for you. It's a nice dream, but I don't see how it has any bearing on reality. Until we can get past this little dream world, I don't see how SIDR is going to make any real progress towards actually securing BGP. Either policies --all policies-- must be off limits, even ones masquerading as "man in the middle attacks," or all policies must be within bounds, and we must enumerate and deal with them honestly. :-) Russ From randy@psg.com Wed Nov 2 11:00:24 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2BF1F0C4B for ; Wed, 2 Nov 2011 11:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSqvnO-3nneU for ; Wed, 2 Nov 2011 11:00:21 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 04F191F0C35 for ; Wed, 2 Nov 2011 11:00:21 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RLf6o-000E6B-Jn; Wed, 02 Nov 2011 18:00:18 +0000 Date: Wed, 02 Nov 2011 19:00:17 +0100 Message-ID: From: Randy Bush To: Russ White In-Reply-To: <4EB180DD.5010401@riw.us> References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <4EB170AD.1030302@riw.us> <4EB180DD.5010401@riw.us> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 18:00:24 -0000 > 1. Most providers apparently want to enforce policy without telling > anyone what their policy actually is. That this is a logical > contradiction doesn't seem to disturb anyone. Policy on the global Internet changes every 36ms, new circuits, new customers, new peers, ... We already have a protocol to distribute policy or its effects, it is called BGP We can not know intent, should Mary have announced the prefix to Bob But Joe can formally validate that Mary did announce the prefix to Bob BGPsec validates that the protocol has not been violated, and is not about intent or business policy randy From brian.peter.dickson@gmail.com Wed Nov 2 11:11:05 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C76B1F0C8C for ; Wed, 2 Nov 2011 11:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VELq3M8hIlu for ; Wed, 2 Nov 2011 11:11:04 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 607881F0C44 for ; Wed, 2 Nov 2011 11:11:04 -0700 (PDT) Received: by faas12 with SMTP id s12so851487faa.31 for ; Wed, 02 Nov 2011 11:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4Rn22efRg4pPuZcpne7bxbPUmkbne8pW2Vs9hED+lHI=; b=pHBgMHsMDtUV7dQG1pA15kjgKnDij/27foaJVrpMlbIL6ESxhIeuAn6mWAl4JKXqgW B973mpg1euLxmpwcVh/IFaTTeINusDVumVNA1aLEy3FfqIWDTSGOi7ysxNyhQ8hg6Gn2 L7GSZObScp+LOp4uYFUTIBsp80Ld8ka67i9xo= MIME-Version: 1.0 Received: by 10.223.91.73 with SMTP id l9mr9999870fam.22.1320257463532; Wed, 02 Nov 2011 11:11:03 -0700 (PDT) Received: by 10.223.54.15 with HTTP; Wed, 2 Nov 2011 11:11:03 -0700 (PDT) In-Reply-To: <4EB180DD.5010401@riw.us> References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <4EB170AD.1030302@riw.us> <4EB180DD.5010401@riw.us> Date: Wed, 2 Nov 2011 14:11:03 -0400 Message-ID: From: Brian Dickson To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 18:11:05 -0000 On Wed, Nov 2, 2011 at 1:41 PM, Russ White wrote: > 1. Most providers apparently want to enforce policy without telling > anyone what their policy actually is. That this is a logical > contradiction doesn't seem to disturb anyone. > > 2. You can't "enforce" your policy --all you can do is signal to someone > else what that policy is, and ask them nicely to enforce it for you. > > 2a. If you have a business relationship with this other party, then you > already have an enforcement mechanism at hand --signatures and other > sorts of things won't provide anything additional. Actually, this is not strictly true. Let's consider the smallest case where there are more than two parties, where route leaks cause problems (whether malicious or accidental). Parties: A, B, C. Relationships, all formalized via contracts (whether for transit or peering). C is a customer of A. C is a customer of B. B and A are peers. For sake of argument, presume that A and B also have upstream transit providers. The intended policies have A and B exchanging routes of only their customers, and their internal routes. C receives the full Internet routing table from both A and B. The agreements between A and C, and between B and C, prohibit C sending anything other than C's own routes to A and B. Then consider what happens in the case of C sending B's routes (and B's upstream routes) to A. A prefers routes learned from customers over peer or transit routes. A now prefers the path via C to the entire Internet, including traffic from A to B. There is no _technological_ mechanism for B to stop this, short of turning down C's BGP session. And, this also presumes that B has some definitive way of discovering this, which is not necessarily the case. When we add in D, a transit customer of C, we can see the challenging nature of the problem. How to we distinguish C sending B's routes to D (which is good and expected and allowed), from C sending B's routes to A (not good/unexpected/not "allowed" by contracts)? If there isn't some easy way for A to see that their customer is sending routes which are not their own or their customers', by way of "marking" in the middle of the AS path, then the scale of the problem is huge (having prefix filters and AS-path filters built on ... the IRR). With marking, we gain easy filtering to honor the senders' intentions, and the ability to authenticate things and still limit the information on a need-to-know basis. Observe the following - information about relationships encoded within the path will be visible only to those who receive the path. If the path signals "block me", the relationship information is also blocked. This may be an acceptable degree of information leakage - which happens to coincide with path information, which necessarily must be leaked. Brian From russw@riw.us Wed Nov 2 11:17:31 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD4911E80F8 for ; Wed, 2 Nov 2011 11:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWOX2NkJeg4A for ; Wed, 2 Nov 2011 11:17:30 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 2581911E80F0 for ; Wed, 2 Nov 2011 11:17:30 -0700 (PDT) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:62493 helo=Russ-Whites-MacBook-Pro.local) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RLfNQ-0004tv-OB; Wed, 02 Nov 2011 14:17:28 -0400 Message-ID: <4EB18937.8010006@riw.us> Date: Wed, 02 Nov 2011 14:17:27 -0400 From: Russ White User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Brian Dickson References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <4EB170AD.1030302@riw.us> <4EB180DD.5010401@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: sidr@ietf.org Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 18:17:31 -0000 >> 2a. If you have a business relationship with this other party, then you >> already have an enforcement mechanism at hand --signatures and other >> sorts of things won't provide anything additional. > > Actually, this is not strictly true. > B and A are peers. Which means they have a business relationship... > The agreements between A and C, and between B and C, prohibit C sending anything > other than C's own routes to A and B. The only way A and B would know they are C's upstream is for them to tell one another about it --as you say, this isn't possible within BGP. According to the folks I've talked to, BGPSEC was specifically not designed to resolve the problem you're discussing, and there is no way within the specification to resolve this problem. :-) Russ From danny@tcb.net Wed Nov 2 17:17:00 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A07B11E8073 for ; Wed, 2 Nov 2011 17:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.036 X-Spam-Level: X-Spam-Status: No, score=-102.036 tagged_above=-999 required=5 tests=[AWL=-0.506, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KN4rD9JN7DS2 for ; Wed, 2 Nov 2011 17:17:00 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6E41F0C36 for ; Wed, 2 Nov 2011 17:17:00 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 12FE5268063; Wed, 2 Nov 2011 18:16:58 -0600 (MDT) Received: from dul1dmcphers-m1.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 02 Nov 2011 18:16:57 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=56790; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <4EB180DD.5010401@riw.us> Date: Wed, 2 Nov 2011 14:12:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <4EB170AD.1030302@riw.us> <4EB180DD.5010401@riw.us> To: Russ White X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 00:17:00 -0000 > 1. Most providers apparently want to enforce policy without telling > anyone what their policy actually is. That this is a logical > contradiction doesn't seem to disturb anyone. While I see it in the BGPSEC requirements work I'm not sure it's "most", = and=20 I don't recall reaching any consensus on this. As an operator and ++450 = peers=20 (and many transit providers) in my day job, I don't have a problem with=20= publishing this information if it helps mitigate what I believe are = threats. I.e., I agree with you.. -danny =20= From danny@tcb.net Wed Nov 2 18:33:02 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D24711E8104 for ; Wed, 2 Nov 2011 18:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIg2uMf+5E6C for ; Wed, 2 Nov 2011 18:32:52 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 70DB811E80BB for ; Wed, 2 Nov 2011 18:32:52 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 29389268063; Wed, 2 Nov 2011 19:32:52 -0600 (MDT) Received: from dul1dmcphers-m1.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 02 Nov 2011 19:32:51 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=57394; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Wed, 2 Nov 2011 21:32:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> To: Stephen Kent X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 01:33:02 -0000 On Nov 2, 2011, at 11:04 AM, Stephen Kent wrote: > The focus of BGPSEC is eBGP, because the concern is verifying the > authenticity of routes arriving from other ASes. The hard problems = arise > for eBGP because these routes are delivered via BGP speakers in = different > "trust domains." iBGP integrity and authenticity can be achieved via = internal security procedures and thus is not a focus of BGPSEC. But given that these attributes and the threat model include internal = BGP=20 speakers and the largest scale issues (e.g., route reflectors with 5 = millions=20 paths _today), we can't simply expect that it's out of scope. > I replied to the ORIGIN attribute question in my other message. >=20 > NLRI and AS_PATH are the attributes being protected both because they = represent the fundamental routing data elements, and because they are = attested to in the RPKI. Using the RPKI we can determine whether the = origin AS is authorized to originate a route for the NLRI. We can verify = whether a BGP speaker representing each AS in the AS_PATH is the entity = that signed the data carried as part of an Update. We don't have = analogous, authoritative data about MPLS, for example, so we can't = provide the same sort of security guarantees. If the community = identifies data carried in Updates that it believes should be protected, = and > we can agree on security semantics that are enforceable relative to = the BGPSEC architecture, then we could expand protection, perhaps in a = v2 of the protocol. But if we add considerable overhead (orders of magnitude from where we are today) to deploy BGPSEC and only focus on a subset of the Path=20 Attribute (i.e., AS_PATH only) integrity functions then the ORIGIN code=20= Path Attribute (and also many others) can still be manipulated to change=20= BGP decision algorithms and induce traffic attraction attacks, then = perhaps we need to challenge the assumptions that led to scoping a solution to=20= AS_PATH and NLRI in the first place, as I really haven't seen a = consensus=20 call on this in the WG either? I think I constitute a participant in "the community" here -- or are we = all=20 expected to accept this large set of documents and assumptions as gospel = =20 and use the SIDR WG as a publication house for work done outside of the=20= IETF? I'd be less uncomfortable if the aim was to publish this set of=20= documents as Experimental until they generate some critical deployment=20= mass, and the broader community refines based upon operational = experience=20 until then, which is something that I'm becoming more amenable to, but = to=20 dictate as "the solution" for secure routing with some many outstanding = issues concerns me. > Beacon frequency affects how responsive BGPSEC is relative to one set = of attacks. A more accurate statement is that the beacon parameters that = the BGPSEC design is likely to use will induce significant latency = detecting those attacks. Reducing the latency would require more = frequent beaconing, and that is viewed as an unacceptable tradeoff, at = lest for now. The residual vulnerability due to beacon latency relates = to the ability of an AS that was authorized to advertise a route, to = replay the advertisement, even when it is not currently authorized to do = so. This vulnerability should be viewed in the context of the inability = of a BGP speaker to know whether a neighbor has failed to withdraw a = route, when it has no paths for the prefix in question. An AS cannot, in = general, know whether the only route for a given prefix has been = withdrawn at some point upstream. This the BGP design and operational = model embodies this vulnerability. And to challenges assumptions, why is beaconing or the current = mechanisms=20 proposed in BGPSEC the right approach -- surely it's something more than = "because we bolted a PKI on to a distributed protocol and this is how it's got to = work? If that's the case, this becomes a prime example of precisely why we don't want to = bolt=20 security on after the fact, particularly in the case of distributed = systems and protocols,=20 and if we're working on 8-10 year out solutions, I'd like to think we = can do better than=20 this. More specifically, if I have perform a cost/benefit analysis it's not at = all clear to me=20 that tightening exposure windows to the frequency (hours/days) you're = suggesting=20 is worth the investment and fundamental shift from the stateful BGP = model we know=20 today, particularly given the drive-by and targeted nature we see in all = other aspects=20 of security today (e.g., APT, phishing, etc..). =20 -danny= From danny@tcb.net Wed Nov 2 19:29:41 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE5C1F0C69 for ; Wed, 2 Nov 2011 19:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.472 X-Spam-Level: X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw94hxtnfcLJ for ; Wed, 2 Nov 2011 19:29:40 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBA41F0C49 for ; Wed, 2 Nov 2011 19:29:40 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 03346268063; Wed, 2 Nov 2011 20:29:40 -0600 (MDT) Received: from dul1dmcphers-m1.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 02 Nov 2011 20:29:39 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=57516; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2-530264728 From: Danny McPherson In-Reply-To: Date: Wed, 2 Nov 2011 22:29:24 -0400 Message-Id: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> To: Stephen Kent X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 02:29:41 -0000 --Apple-Mail-2-530264728 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 2, 2011, at 10:52 AM, Stephen Kent wrote: > I interpret the task at hand as trying to secure BGP, not a new EGP. = Since BGP semantics (and syntax) do not provide a basis for deciding = when an advertisement constitutes a route leak, I think it reasonable = that the BGPSEC threat model view this as out of scope. If BGP were = modified to express semantics we're discussing, then it would be in = scope, and I would expect BGPSEC to address it. Duly noted, and my disagreement stands: To say that BGP routes "leaked" via an AS for purposes of MITM, DoS, or benign, that is not an authorized transit for a given prefix is out of = scope=20 because it is not a "semantics violation" does not mitigate what I = perceive=20 as a very significant risk to my operations. =20 Absent a companion set of mechanisms and controls under cover of = "BGPSEC"=20 to mitigate that risk, I'm opposed to the publication of this document = under the=20 auspices of "Threat Model for BGP Path Security". I.e., it is not an = acceptable=20 residual risk. > yes, one can use RPSL to express more info, but these are just = assertions > by the maintainers of RPSL objects. But if these maintainers are the resource holders that are authorized = via the RPKI, then they are no more assertions than an RIR's RPKI testimony = about=20 their resource holdings is an assertion. =20 > For some of this data, there is no basis for validating it via = external, authoritative > sources. That makes such data a poor basis for security controls. Ahh, and the crux - then perhaps this needs to be corrected, rather than=20= accepting this residual risk? > We disagree about the advisability of relying on some types of IRR = data, e.g., an assertion that AS X will advertise (not originate) routes = for prefix Z. "Some types" is relative, and I understand and agree with that. Tell me how to get there? > Sorry, I misunderstood your question. Now I know the data item to = which you were referring. I checked with a network operator here at the = RIPE meetings, to understand how/why it is used. I now believe that the = ORIGIN attribute is a poster boy for an attribute that is unsuitable for = inter-AS protection. This attribute can be set to one of 3 values by an = AS sending an Update. (One of these values cites EGP as the source of = the data, so unless the Update has been terribly delayed, this is not a = credible value :-).) The other two values are IGP and INCOMPLETE (i.e., = mystery). How would an AS that sees this value externally verify that = the value is accurate? I am unable to imagine how this would work. If it were cryptographically protected by the origin AS then it couldn't = be manipulated by intermediate ASes for the purpose of traffic attraction=20= attacks - as it commonly is today. As discussed above, ORIGIN code was=20= simply an example of why the laser focus only on the AS_PATH Path=20 Attributes may be problematic in practice. > Let me try again. If we can't identify a suitable, authoritative = source of data that could be used to verify an assertion about an = attribute in an Update, that attribute is not a candidate for inter-AS = security mechanisms. If an origin AS for which a ROA is associated in the current system = signs=20 those transitive attributes then what more do you need? =20 > How does BGP indicate (i.e., where are the bits that say) that the = Update sent to E is not to be propagated to another ISP? I've been told = that the NO_EXPORT community does not have the right semantics, and that = network operators do not pay attention to this anyway. I agree NO_EXPORT is not the right answer, I never even considered it. =20= I'm saying policy is a big part of the problem, at least as considerable = as =20 "integrity" of the AS_PATH, IMO, and if we don't take a systemic = approach=20 and consider the gaps that exist, then it's hard for me to justify the=20= investment. >> But it "may" be externally detectable, which was my point that >> you've reinforced :-) >=20 > "May" is not a suitable basis for a secruity protocol :-). The possibly exists that it many cases it can be detected, therefore, = "cannot"=20 is false. > I can add text to note that use of cached data enables some types of = attacks resulting from use of stale data. I think the text we need here, if you truly believe this is the right = course,=20 is to clearly state that expired digital certificate data is acceptable. = As a=20 basis for a security architecture, this assumption seems a residual risk = I=20 would prefer to mitigate. For example, do you consider it acceptable to use expired certs when=20 you connect to a web site via SSL or VPN to some remote location? I=20 don't. Furthermore, besides the obvious attacks you're accepting by = recommending use of expired certificates, aren't revoked certificates only supposed = to remain=20 in the CRL until their validity period has expired? How in the heck can = we justify=20 use of expired certificates in the absence of current data, when some of = those=20 expired certificates may have even been revoked? > In PKIs it is always the case that, in the absence of the current CRL, = use the old one. This is because, with one ugly exception, once you are = revoked, you are revoked, you stay revoked. So, expired and stale are = meaningful differences to us PKI experts. But, I agree that more text = can be added to note the vulnerabilities associated with using stale or = expired PKI data. And that is exactly my point, I don't know the difference between them and therefore using them opens me up to attack and undermines the entire system. Also, if RPKI weren't so distributed, or if we could develop a model, = perhaps some OSCP-esque near realtime function would be of benefit here, in the = general case,=20 and perhaps even some notify function from publication points/CAs for = RPs to identify=20 revoked certificates, such that a RP, or even BGPSEC speakers, could be = notified of an incident with a particular resource, rather than periodically telling = everyone=20 everything via a periodic update/refresh mechanism?=20 What are your thoughts on this? -danny --Apple-Mail-2-530264728 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Nov 2, 2011, at 10:52 AM, Stephen = Kent wrote:

I = interpret the task at hand as trying to secure BGP, not a new EGP. Since = BGP semantics (and syntax) do not provide a basis for deciding when an = advertisement constitutes a route leak, I think it reasonable that the = BGPSEC threat model view this as out of scope. If BGP were modified to = express semantics we're discussing, then it would be in scope, and I = would expect BGPSEC to address = it.

Duly noted, and my = disagreement stands:

To say that BGP = routes "leaked" via an AS for purposes of MITM, DoS, = or
benign, that is not an authorized transit for a = given prefix is out of scope 
because it is not = a "semantics violation" does not mitigate what I = perceive 
as  a very significant risk to my = operations.  

Absent a companion set of = mechanisms and controls under cover of "BGPSEC" 
to = mitigate that risk, I'm opposed to the publication of this = document under the 
auspices =  of  "Threat Model for BGP Path Security". =  I.e., it is not an acceptable 
residual = risk.

yes, one can use = RPSL to express more info, but these are just = assertions
by the maintainers = of RPSL objects.

But if these maintainers = are the resource holders that are authorized via the
RPKI, = then they are no more assertions than an RIR's RPKI testimony = about 
their resource holdings is = an assertion.
 
For = some of this data, there is no basis for validating it via external, = authoritative
sources. That makes = such data a poor basis for security = controls.

Ahh, and the crux - then perhaps = this needs to be corrected, rather than 
accepting this = residual risk?

We = disagree about the advisability of relying on some types of IRR data, = e.g., an assertion that AS X will advertise (not originate) routes for = prefix Z.

"Some = types" is relative, and I understand and agree with that.  Tell = me
how to get there?

 unsuitable for inter-AS protection. = This attribute can be set to one of 3 values by an AS sending an Update. = (One of these values cites EGP as the source of the data, so unless the = Update has been terribly delayed, this is not a credible value = :-).)  The other two values are IGP and INCOMPLETE (i.e., mystery). = How would an AS that sees this value externally verify that the value is = accurate? I am unable to imagine how this would = work.

If it were = cryptographically protected by the origin AS then it couldn't = be
manipulated by intermediate ASes for the purpose of traffic = attraction 
attacks - as it commonly is today. =  As discussed above, ORIGIN code was 
simply an = example of why the laser focus only on the AS_PATH = Path 
Attributes may be problematic in = practice.

Let = me try again. If we can't identify a suitable, authoritative source of = data that could be used to verify an assertion about an attribute in an = Update, that attribute is not a candidate for inter-AS security = mechanisms.

If an = origin AS for which a ROA is associated in the current system = signs 
those transitive attributes then what more do you = need?  

How = does BGP indicate (i.e., where are the bits that say) that the Update = sent to E is not to be propagated to another ISP?  I've been told = that the NO_EXPORT community does not have the right semantics, and that = network operators do not pay attention to this = anyway.

I agree = NO_EXPORT is not the right answer, I never even considered it. =  

I'm saying policy is a big part of = the problem, at least as considerable as  
"integrity" of = the AS_PATH, IMO, and if we don't take a systemic = approach 
and consider the gaps that exist, then it's = hard for me to justify = the 
investment.

But it "may" be externally detectable, which was = my point that
you've reinforced = :-)

"May" is not a suitable basis for a = secruity protocol :-).

The = possibly exists that it many cases it can be detected, therefore, = "cannot" 
is false.

I = can add text to note that use of cached data enables some types of = attacks resulting from use of stale = data.

I think the = text we need here, if you truly believe this is the right = course, 
is to clearly state that expired digital = certificate data is acceptable.  As a 
basis for a = security architecture, this assumption seems a residual risk = I 
would prefer to mitigate.

For = example, do you consider it acceptable to use expired certs = when 
you connect to a web site via SSL or VPN to some = remote location? =  I 
don't.

Furthermore, = besides the obvious attacks you're accepting by = recommending
use of expired certificates, aren't revoked = certificates only supposed to remain 
in the = CRL until their validity period has expired?  How in the = heck can we justify 
use of expired certificates in = the absence of current data, when some of = those 
expired certificates may have even been = revoked?

In = PKIs it is always the case that, in the absence of the current CRL, use = the old one. This is because, with one ugly exception, once you are = revoked, you are revoked, you stay revoked. So, expired and stale are = meaningful differences to us PKI experts. But, I agree that more text = can be added to note the vulnerabilities associated with using stale or = expired PKI data.

And that = is exactly my point, I don't know the difference between = them
and therefore using them opens me up to attack and = undermines the entire
system.

Also, = if RPKI weren't so distributed, or if we could develop a model, perhaps = some
OSCP-esque near realtime function would be of benefit = here, in the general case, 
and perhaps even some = notify function from publication points/CAs for RPs to = identify 
revoked certificates, such that a RP, or = even BGPSEC speakers, could be notified of
an incident with a = particular resource, rather than periodically telling = everyone 
everything via a periodic update/refresh = mechanism? 

What are your thoughts on = this?

-danny


<= /body>= --Apple-Mail-2-530264728-- From kent@bbn.com Thu Nov 3 04:10:31 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E8D1F0C89 for ; Thu, 3 Nov 2011 04:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.478 X-Spam-Level: X-Spam-Status: No, score=-106.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgFj7tf1n6A5 for ; Thu, 3 Nov 2011 04:10:29 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 682F81F0C81 for ; Thu, 3 Nov 2011 04:10:29 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:44036 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RLvAm-0006RU-1Y; Thu, 03 Nov 2011 07:09:28 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> Date: Thu, 3 Nov 2011 07:09:14 -0400 To: Danny McPherson From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-891803929==_ma============" Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 11:10:31 -0000 --============_-891803929==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 10:29 PM -0400 11/2/11, Danny McPherson wrote: >On Nov 2, 2011, at 10:52 AM, Stephen Kent wrote: > >>I interpret the task at hand as trying to secure BGP, not a new >>EGP. Since BGP semantics (and syntax) do not provide a basis for >>deciding when an advertisement constitutes a route leak, I think it >>reasonable that the BGPSEC threat model view this as out of scope. >>If BGP were modified to express semantics we're discussing, then it >>would be in scope, and I would expect BGPSEC to address it. >> > >Duly noted, and my disagreement stands: > >To say that BGP routes "leaked" via an AS for purposes of MITM, DoS, or >benign, that is not an authorized transit for a given prefix is out of scope >because it is not a "semantics violation" does not mitigate what I perceive >as a very significant risk to my operations. > >Absent a companion set of mechanisms and controls under cover of "BGPSEC" >to mitigate that risk, I'm opposed to the publication of this >document under the >auspices of "Threat Model for BGP Path Security". I.e., it is not >an acceptable >residual risk. Having been motived to reread the SIDR charter by Brian's message, there is a simple answer to the in/out of scope question, but it's one you will not like :-). The charter for SIDR states that the secruity goals for the WG are to address two vulnerabilities: authorization for prefix origination and path validation. Relative to the charter, route leaks are out of scope. I will add text to the intro for the threat model to state that the scope of the model is defined by the charter, and include the relevant charter text. I hope you'll forgive me for taking the easy path here. >>yes, one can use RPSL to express more info, but these are just assertions >> >>by the maintainers of RPSL objects. >> > >But if these maintainers are the resource holders that are authorized via the >RPKI, then they are no more assertions than an RIR's RPKI testimony about >their resource holdings is an assertion. I'm not sure I understand the sentence above. RPKI CAs issue certs based on authoritative databases about Internet resources. The authorized holder of a resource can make lots of assertions, and the RPKI allows us to attribute these assertions to that entity. RPSL allows lots of assertions to be made, and many of them cannot be validated relative to the RPKI. Relying on such assertions, just because their sigs can be validated under the RPKI is a new sort of vulnerability that we ought not enable. >> For some of this data, there is no basis for validating it via >>external, authoritative >> >>sources. That makes such data a poor basis for security controls. >> > >Ahh, and the crux - then perhaps this needs to be corrected, rather than >accepting this residual risk? see comment above. > >>We disagree about the advisability of relying on some types of IRR >>data, e.g., an assertion that AS X will advertise (not originate) >>routes for prefix Z. >> > >"Some types" is relative, and I understand and agree with that. Tell me >how to get there? Get where? > >>Sorry, I misunderstood your question. Now I know the data item to >>which you were referring. I checked with a network operator here at >>the RIPE meetings, to understand how/why it is used. I now believe >>that the ORIGIN attribute is a poster boy for an attribute that >>is unsuitable for inter-AS protection. This attribute can be set to >>one of 3 values by an AS sending an Update. (One of these values >>cites EGP as the source of the data, so unless the Update has been >>terribly delayed, this is not a credible value :-).) The other two >>values are IGP and INCOMPLETE (i.e., mystery). How would an AS that >>sees this value externally verify that the value is accurate? I am >>unable to imagine how this would work. >> > >If it were cryptographically protected by the origin AS then it couldn't be >manipulated by intermediate ASes for the purpose of traffic attraction >attacks - as it commonly is today. As discussed above, ORIGIN code was >simply an example of why the laser focus only on the AS_PATH Path >Attributes may be problematic in practice. I agree that the integrity that would result from including this attribute under the sig applied by the first AS would provide the secruity you cited. That may make it worthwhile to protect via the sig. However, the accuracy of the assertion being made by this attribute is unverifiable by any of the ASes along the path, and that was what worried me. But, again, the charter makes this out of scope, i.e., it is not relevant to the origin authorization or path accuracy vulnerabilities cited there. >>Let me try again. If we can't identify a suitable, authoritative >>source of data that could be used to verify an assertion about an >>attribute in an Update, that attribute is not a candidate for >>inter-AS security mechanisms. >> > >If an origin AS for which a ROA is associated in the current system signs >those transitive attributes then what more do you need? That sig provides integrity, which is valuable, but it does not provide a way to verify the accuracy of the assertion by the origin AS. Your concern is that an AS along the route can change the value of the attribute. One might also be concerned that the origin set the value incorrectly. Ultimately, I think this is a bad example for us to argue about, as it is a vestigial part of BGP, from EGP days, that is the penultimate basis for route decisions. >> How does BGP indicate (i.e., where are the bits that say) that the >>Update sent to E is not to be propagated to another ISP? I've been >>told that the NO_EXPORT community does not have the right >>semantics, and that network operators do not pay attention to this >>anyway. >> > >I agree NO_EXPORT is not the right answer, I never even considered it. > >I'm saying policy is a big part of the problem, at least as considerable as >"integrity" of the AS_PATH, IMO, and if we don't take a systemic approach >and consider the gaps that exist, then it's hard for me to justify the >investment. I'm not sure what you're trying to say about policy here. Can you elaborate. > >>>But it "may" be externally detectable, which was my point that >>> >>>you've reinforced :-) >>> >> >>"May" is not a suitable basis for a secruity protocol :-). >> > >The possibly exists that it many cases it can be detected, therefore, "cannot" >is false. OK, "cannot" was too strong. But, I still feel that "may" is a bad basis for a security protocol. >>I can add text to note that use of cached data enables some types >>of attacks resulting from use of stale data. >> > >I think the text we need here, if you truly believe this is the right course, >is to clearly state that expired digital certificate data is acceptable. As a >basis for a security architecture, this assumption seems a residual risk I >would prefer to mitigate. It is up to each RP to decide whether to rely on assertions made by an expired cert, or to act as though the cert does not exist. In the routing context, there appears to be some agreement that relying on expired certs is more desirable than treating the resources as not certified. But, this is a per-RP decision. >For example, do you consider it acceptable to use expired certs when >you connect to a web site via SSL or VPN to some remote location? I >don't. Many folks do. This is probably because an expired cert often indicates that the cert holder was sloppy, and failed to renew the cert, i.e., pay the CA. Expiration is not as negative an indication as revocation. >Furthermore, besides the obvious attacks you're accepting by recommending >use of expired certificates, aren't revoked certificates >only supposed to remain >in the CRL until their validity period has expired? How in the >heck can we justify >use of expired certificates in the absence of current data, when some of those >expired certificates may have even been revoked? There is a subtly here, and thanks for pointing it out. The idea is that if an RP has a cert, and it was not revoked, then the RP can continue to rely on it, after the cert expires, if the RP is unable to acquire fresh data from the pub point for that cert. If the cert had been revoked, it should not be un-revoked because it expired. >>In PKIs it is always the case that, in the absence of the current >>CRL, use the old one. This is because, with one ugly exception, >>once you are revoked, you are revoked, you stay revoked. So, >>expired and stale are meaningful differences to us PKI experts. >>But, I agree that more text can be added to note the >>vulnerabilities associated with using stale or expired PKI data. >> > >And that is exactly my point, I don't know the difference between them >and therefore using them opens me up to attack and undermines the entire >system. I think the phrase "undermines the entire system" is melodramatic. How about "you actual assurance may vary?" :-) >Also, if RPKI weren't so distributed, or if we could develop a >model, perhaps some >OSCP-esque near realtime function would be of benefit here, in the >general case, >and perhaps even some notify function from publication points/CAs >for RPs to identify >revoked certificates, such that a RP, or even BGPSEC speakers, could >be notified of >an incident with a particular resource, rather than periodically >telling everyone >everything via a periodic update/refresh mechanism? > >What are your thoughts on this? I would prefer more centralization of RPKI data. My original model called for each RIR to aggregate the data for every member, and act as a mirror for the data for every other RIR. But other folks wanted greater distribution. One can argue that wider distribution may offer potentially greater resilience, so ... OCSP is an optimization of the CRL mechanism, designed to efficiently answer a revocation status query for a single cert. Since every RP needs to know the revocation status of every cert, OCSP (or an analogous mechanism) does not seem to be a good match. For many years folks have thought that very fast dissemination of revocation status data was important for PKIs. In reality, revocation is an administrative procedure for which the major delays will be created by people deciding whether to revoke a cert, vs. the time it takes to disseminate the CRL. There are two types of certs: CA certs and EE certs. Because revoking a CA cert has major implications, so such a decision will not be taken lightly. Thus I expect relatively few revocations of CA certs and the principle delay will be procedural. All of the EE certs defined so far (not counting router certs for BGPSEC, which have yet to be agreed upon) are embedded in RPKI objects: manifests, ROAs, and GB records. A new manifest MUST be published whenever any file at a pub point changes. The CPS template recommends daily CRL issuance, and that seems to be what the RIRs are doing for the pub points that they maintain . Thus it is likely that a new manifest will be issued every day. So, I doubt that many manifest cert will be revoked. The GB record is likely to be very stable, as it provides contact info for the pub point maintainer. I don't see freshness attacks on these records as a big deal. A ROA expresses a binding between a prefix and an ASN. I would expect most of these to be fairly stable, and that operators would follow a make-before-break policy. That suggests that ROA cert revocation will be relatively infrequent, and will not require immediate dissemination. So, I am not convinced that there is a need for a different approach to disseminating revocation status. Steve --============_-891803929==_ma============ Content-Type: text/html; charset="us-ascii" Re: [sidr] BGPSEC Threat Model ID
At 10:29 PM -0400 11/2/11, Danny McPherson wrote:
On Nov 2, 2011, at 10:52 AM, Stephen Kent wrote:

I interpret the task at hand as trying to secure BGP, not a new EGP. Since BGP semantics (and syntax) do not provide a basis for deciding when an advertisement constitutes a route leak, I think it reasonable that the BGPSEC threat model view this as out of scope. If BGP were modified to express semantics we're discussing, then it would be in scope, and I would expect BGPSEC to address it.

Duly noted, and my disagreement stands:

To say that BGP routes "leaked" via an AS for purposes of MITM, DoS, or
benign, that is not an authorized transit for a given prefix is out of scope
because it is not a "semantics violation" does not mitigate what I perceive
as  a very significant risk to my operations.

Absent a companion set of mechanisms and controls under cover of "BGPSEC"
to mitigate that risk, I'm opposed to the publication of this document under the
auspices  of  "Threat Model for BGP Path Security".  I.e., it is not an acceptable
residual risk.

Having been motived to reread the SIDR charter by Brian's message, there is a simple answer to the in/out of scope question, but it's one you will not like :-). The charter for SIDR states that the secruity goals for the WG are to address two vulnerabilities: authorization for prefix origination and path validation.  Relative to the charter, route leaks are out of scope.  I will add text to the intro for the threat model to state that the scope of the model is defined by the charter, and include the relevant charter text. I hope you'll forgive me for taking the easy path here.

yes, one can use RPSL to express more info, but these are just assertions
by the maintainers of RPSL objects.

But if these maintainers are the resource holders that are authorized via the
RPKI, then they are no more assertions than an RIR's RPKI testimony about
their resource holdings is an assertion.

I'm not sure I understand the sentence above.  RPKI CAs issue certs based on authoritative databases about Internet resources.  The authorized holder of a resource can make lots of assertions, and the RPKI allows us to attribute these assertions to that entity. RPSL allows lots of assertions to be made, and many of them cannot be validated relative to the RPKI. Relying on such assertions, just because their sigs can be validated under the RPKI is a new sort of vulnerability that we ought not enable.

 For some of this data, there is no basis for validating it via external, authoritative
sources. That makes such data a poor basis for security controls.

Ahh, and the crux - then perhaps this needs to be corrected, rather than
accepting this residual risk?

see comment above. 

We disagree about the advisability of relying on some types of IRR data, e.g., an assertion that AS X will advertise (not originate) routes for prefix Z.

"Some types" is relative, and I understand and agree with that.  Tell me
how to get there?

Get where?


Sorry, I misunderstood your question. Now I know the data item to which you were referring. I checked with a network operator here at the RIPE meetings, to understand how/why it is used.  I now believe that the ORIGIN attribute is a poster boy for an attribute that is unsuitable for inter-AS protection. This attribute can be set to one of 3 values by an AS sending an Update. (One of these values cites EGP as the source of the data, so unless the Update has been terribly delayed, this is not a credible value :-).)  The other two values are IGP and INCOMPLETE (i.e., mystery). How would an AS that sees this value externally verify that the value is accurate? I am unable to imagine how this would work.

If it were cryptographically protected by the origin AS then it couldn't be
manipulated by intermediate ASes for the purpose of traffic attraction
attacks - as it commonly is today.  As discussed above, ORIGIN code was
simply an example of why the laser focus only on the AS_PATH Path
Attributes may be problematic in practice.

I agree that the integrity that would result from including this attribute under the sig applied by the first AS would provide the secruity you cited. That may make it worthwhile to protect via the sig. However, the accuracy of the assertion being made by this attribute is unverifiable by any of the ASes along the path, and that was what worried me.  But, again, the charter makes this out of scope, i.e., it is not relevant to the origin authorization or path accuracy vulnerabilities cited there.

Let me try again. If we can't identify a suitable, authoritative source of data that could be used to verify an assertion about an attribute in an Update, that attribute is not a candidate for inter-AS security mechanisms.

If an origin AS for which a ROA is associated in the current system signs
those transitive attributes then what more do you need?

That sig provides integrity, which is valuable, but it does not provide a way to verify the accuracy of the assertion by the origin AS. Your concern is that an AS along the route can change the value of the attribute. One might also be concerned that the origin set the value incorrectly. Ultimately, I think this is a bad example for us to argue about, as it is a vestigial part of BGP, from EGP days, that is the penultimate basis for route decisions.

 How does BGP indicate (i.e., where are the bits that say) that the Update sent to E is not to be propagated to another ISP?  I've been told that the NO_EXPORT community does not have the right semantics, and that network operators do not pay attention to this anyway.

I agree NO_EXPORT is not the right answer, I never even considered it.

I'm saying policy is a big part of the problem, at least as considerable as
"integrity" of the AS_PATH, IMO, and if we don't take a systemic approach
and consider the gaps that exist, then it's hard for me to justify the
investment.

I'm not sure what you're trying to say about policy here. Can you elaborate.


But it "may" be externally detectable, which was my point that
you've reinforced :-)

"May" is not a suitable basis for a secruity protocol :-).

The possibly exists that it many cases it can be detected, therefore, "cannot"
is false.

OK, "cannot" was too strong. But, I still feel that "may" is a bad basis for a security protocol.

I can add text to note that use of cached data enables some types of attacks resulting from use of stale data.

I think the text we need here, if you truly believe this is the right course,
is to clearly state that expired digital certificate data is acceptable.  As a
basis for a security architecture, this assumption seems a residual risk I
would prefer to mitigate.

It is up to each RP to decide whether to rely on assertions made by an expired cert, or to act as though the cert does not exist. In the routing context, there appears to be some agreement that relying on expired certs is more desirable
than treating the resources as not certified. But, this is a per-RP decision.

For example, do you consider it acceptable to use expired certs when
you connect to a web site via SSL or VPN to some remote location?  I
don't.

Many folks do. This is probably because an expired cert often indicates that
the cert holder was sloppy, and failed to renew the cert, i.e., pay the CA. Expiration is not as negative an indication as revocation.

Furthermore, besides the obvious attacks you're accepting by recommending
use of expired certificates, aren't revoked certificates only supposed to remain
in the CRL until their validity period has expired?  How in the heck can we justify
use of expired certificates in the absence of current data, when some of those
expired certificates may have even been revoked?

There is a subtly here, and thanks for pointing it out. The idea is that if an RP has a cert, and it was not revoked, then the RP can continue to rely on it, after the cert expires, if the RP is unable to acquire fresh data from the pub point for that cert. If the cert had been revoked, it should not be un-revoked because it expired.

In PKIs it is always the case that, in the absence of the current CRL, use the old one. This is because, with one ugly exception, once you are revoked, you are revoked, you stay revoked. So, expired and stale are meaningful differences to us PKI experts. But, I agree that more text can be added to note the vulnerabilities associated with using stale or expired PKI data.


And that is exactly my point, I don't know the difference between them
and therefore using them opens me up to attack and undermines the entire
system.

I think the phrase "undermines the entire system" is melodramatic. How about "you actual assurance may vary?" :-)

Also, if RPKI weren't so distributed, or if we could develop a model, perhaps some
OSCP-esque near realtime function would be of benefit here, in the general case,
and perhaps even some notify function from publication points/CAs for RPs to identify
revoked certificates, such that a RP, or even BGPSEC speakers, could be notified of
an incident with a particular resource, rather than periodically telling everyone
everything via a periodic update/refresh mechanism?

What are your thoughts on this?

I would prefer more centralization of RPKI data. My original model called for each RIR to aggregate the data for every member, and act as a mirror for the data for every other RIR. But other folks wanted greater distribution. One can argue that wider distribution may offer potentially greater resilience, so ...

OCSP is an optimization of the CRL mechanism, designed to efficiently answer a revocation status query for a single cert. Since every RP needs to know the revocation  status of every cert, OCSP (or an analogous mechanism) does not seem to be a good match.  For many years folks have thought that very fast dissemination of revocation status data was important for PKIs.  In reality, revocation is an administrative procedure for which the major delays will be
created by people deciding whether to revoke a cert, vs. the time it takes to disseminate the CRL.

There are two types of certs: CA certs and EE certs.

Because revoking a CA cert has major implications, so such a decision will not be taken lightly. Thus I expect relatively few revocations of CA certs and the principle delay will be procedural.

All of the EE certs defined so far (not counting router certs for BGPSEC, which have yet to be agreed upon) are embedded in RPKI objects: manifests, ROAs, and GB records.

A new manifest MUST be published whenever any file at a pub point changes. The CPS template recommends daily CRL issuance, and that seems to be what the RIRs are doing for the pub points that they maintain . Thus it is likely that a new manifest will be issued every day. So, I doubt that many manifest cert will be revoked.

The GB record is likely to be very stable, as it provides contact info for the pub point maintainer. I don't see freshness attacks on these records as a big deal.

A ROA expresses a binding between a prefix and an ASN. I would expect most of these to be fairly stable, and that operators would follow a make-before-break policy. That suggests that ROA cert revocation will be relatively infrequent, and will not require immediate dissemination.

So, I am not convinced that there is a need for a different approach to disseminating revocation status.

Steve
--============_-891803929==_ma============-- From russw@riw.us Thu Nov 3 05:00:09 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F9C11E80D2 for ; Thu, 3 Nov 2011 05:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZR+kuoD3FebK for ; Thu, 3 Nov 2011 05:00:08 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA6911E8088 for ; Thu, 3 Nov 2011 05:00:08 -0700 (PDT) Received: from rtp-isp-nat1.cisco.com ([64.102.254.33]:53848 helo=[10.117.153.102]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RLvxm-0002jg-Jl for sidr@ietf.org; Thu, 03 Nov 2011 08:00:06 -0400 Message-ID: <4EB28247.8010604@riw.us> Date: Thu, 03 Nov 2011 08:00:07 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sidr@ietf.org References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 12:00:09 -0000 > To say that BGP routes "leaked" via an AS for purposes of MITM, DoS, or > benign, that is not an authorized transit for a given prefix is out of > scope > because it is not a "semantics violation" does not mitigate what I perceive > as a very significant risk to my operations. This is something of an aside --but I find the entire discussion about "semantics violations" a bit of a red herring. If we are to secure every possible "semantic violation," then we should also be securing communities, next hops, and verifying the AS of the peering router is actually the AS contained in the AS Path --in a way that operators multiple hops away can check. These are all also "BGP semantics," not just the AS Path. > Absent a companion set of mechanisms and controls under cover of "BGPSEC" > to mitigate that risk, I'm opposed to the publication of this document > under the > auspices of "Threat Model for BGP Path Security". I.e., it is not an > acceptable > residual risk. The bottom line issue --as I see it-- is that we've never properly defined the problem space. To secure something requires that everyone understand the intent, whether by implying it from inband signaling, or knowing it through out of band signaling. SIDR --and hence this threats document-- has been going down the path of "we want security without knowing intent." A logical impossibility. So, I agree with Danny --this document doesn't cover the threat space, and shouldn't be published. Instead, we need a real analysis of the entire threat space, without regard to the difficulty of actually securing that space. > I'm saying policy is a big part of the problem, at least as considerable > as > "integrity" of the AS_PATH, IMO, and if we don't take a systemic approach > and consider the gaps that exist, then it's hard for me to justify the > investment. To put this in different terms: 1. You can't know if something is "secure" without knowing the intent of the "authorizer." 2. You can't know someone's intent unless they tell you --inferring intent is dangerous and bad. 3. Hence, securing a system without advertising intent is impossible. 4. Intent == policy. 5. If you're going to include policy, then you need to consider all policy, and not just a narrow range of policy "because this is what I care about, and it's what also happens to be easy to secure." Whether intent should be transmitted in band or out of band is a matter of open discussion (though I think we must either resolve to change the nature of BGP, or resolve to signal intent out of band). :-) Russ From danny@tcb.net Thu Nov 3 05:06:27 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F51C1F0C89 for ; Thu, 3 Nov 2011 05:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.261 X-Spam-Level: X-Spam-Status: No, score=-101.261 tagged_above=-999 required=5 tests=[AWL=-1.121, BAYES_00=-2.599, FB_YOU_CAN_BECOME=1.258, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM4iqTUvU9rm for ; Thu, 3 Nov 2011 05:06:25 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5761F0C70 for ; Thu, 3 Nov 2011 05:06:25 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 110D13780E3; Thu, 3 Nov 2011 06:06:25 -0600 (MDT) Received: from dul1dmcphers-m1.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 03 Nov 2011 06:06:24 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=58078; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-564869998 From: Danny McPherson In-Reply-To: Date: Thu, 3 Nov 2011 08:06:09 -0400 Message-Id: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> To: Stephen Kent X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 12:06:27 -0000 --Apple-Mail-1-564869998 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 3, 2011, at 7:09 AM, Stephen Kent wrote: > Having been motived to reread the SIDR charter by Brian's message, = there is a simple answer to the in/out of scope question, but it's one = you will not like :-). The charter for SIDR states that the secruity = goals for the WG are to address two vulnerabilities: authorization for = prefix origination and path validation. Relative to the charter, route = leaks are out of scope. I will add text to the intro for the threat = model to state that the scope of the model is defined by the charter, = and include the relevant charter text. I hope you'll forgive me for = taking the easy path here. I do not... The charter is temporal and the product of the WG in the form of RFCs=20 will be much more persistent, I'm concerned by a line of reasoning that=20= says "Let's ignore and not even enumerate or concern ourselves with=20 these obvious threats because the current charter [deliberately] says=20 all we have to do is provide semantic validation of the AS_PATH" [and=20 doing anything more would quite possibly NOT be conducive to=20 expedited publication of BGPSEC]. =20 > I agree that the integrity that would result from including this = attribute under the sig applied by the first AS would provide the = secruity you cited. That may make it worthwhile to protect via the sig. = However, the accuracy of the assertion being made by this attribute is = unverifiable by any of the ASes along the path, and that was what = worried me. But, again, the charter makes this out of scope, i.e., it = is not relevant to the origin authorization or path accuracy = vulnerabilities cited there. NIce, another threat that shouldn't be listed because it's not in the = charter=20 as written or addressed via BGPSEC as is. If that's the case, then all = the=20 drafts should include the current revision of the charter and explicit = text about=20 ignoring all other threats under these auspices. > That sig provides integrity, which is valuable, but it does not = provide a way to verify the accuracy of the assertion by the origin AS. = Your concern is that an AS along the route can change the value of the = attribute. One might also be concerned that the origin set the value = incorrectly. Ultimately, I think this is a bad example for us to argue = about, as it is a vestigial part of BGP, from EGP days, that is the = penultimate basis for route decisions. No, it is used today and opens up traffic attraction attacks, please = don't=20 brush it aside because it's 'penultimate' in the decision process - it = is=20 there and it impacts traffic today. > It is up to each RP to decide whether to rely on assertions made by an = expired cert, or to act as though the cert does not exist. In the = routing context, there appears to be some agreement that relying on = expired certs is more desirable > than treating the resources as not certified. But, this is a per-RP = decision. There is only room for two states, right? Valid and not valid. Stale = =3D=3D not valid. > Many folks do. This is probably because an expired cert often = indicates that > the cert holder was sloppy, and failed to renew the cert, i.e., pay = the CA. Expiration is not as negative an indication as revocation. Or because a CA was compromised - we've seen this in the real world with increased frequency, as you well know. > There is a subtly here, and thanks for pointing it out. The idea is = that if an RP has a cert, and it was not revoked, then the RP can = continue to rely on it, after the cert expires, if the RP is unable to = acquire fresh data from the pub point for that cert. If the cert had = been revoked, it should not be un-revoked because it expired. And therefore we MUST NOT rely on expired certificates, period. > I think the phrase "undermines the entire system" is melodramatic. How = about "you actual assurance may vary?" :-) "house of cards", "village of cards"... > I would prefer more centralization of RPKI data. My original model = called for each RIR to aggregate the data for every member, and act as a = mirror for the data for every other RIR. But other folks wanted greater = distribution. One can argue that wider distribution may offer = potentially greater resilience, so ... Yeah, I get it -- until you get to the point where you have to use = expired=20 certificates in a PKI and they may have been revoked or may no longer=20 be valid or intended for use but because you can't pick certificates up=20= from some remote portion of the Internet then you relay on stale (i.e.,=20= NOT valid) data. Even if "more distributed", I'm not sure that's added=20= resilience, particularly when PKI is employed. > OCSP is an optimization of the CRL mechanism, designed to efficiently = answer a revocation status query for a single cert. Since every RP needs = to know the revocation status of everycert, OCSP (or an analogous = mechanism) does not seem to be a good match. For many years folks have = thought that very fast dissemination of revocation status data was = important for PKIs. In reality, revocation is an administrative = procedure for which the major delays will be > created by people deciding whether to revoke a cert, vs. the time it = takes to disseminate the CRL. And I'm saying that if we're going to employ a PKI solution on a = distributed=20 loosely coherent resource certification infrastructure that's going to = be employed=20 by RPs in a non-determinsitc manner and result in "periodic updates" in = the=20 routing system in order to minimize exposure windows, then we ought to = look=20 at what architectural approaches can be considered or what new elements=20= invented to minimize unneeded state and churn in the network and = maximize=20 resiliency without introducing the possibly for any array of new = attacks. We've already seen issues where such an approach has been problematic = with=20 DNSSEC in the wake of portions of the Internet being fragmented and = causing=20 issues and inability to update certificates in the system at root, TLD = and SLD=20 levels, and what you're proposing here is far far more troubling. > There are two types of certs: CA certs and EE certs. >=20 > Because revoking a CA cert has major implications, so such a decision = will not be taken lightly. Thus I expect relatively few revocations of = CA certs and the principle delay will be procedural. Yes, just as with SSL certificates today - but when they do happen, the = more quickly you can become aware of that revocation the better off you;re = going to=20 be -- and it's all still inherently reactive from a controls = perspective. > All of the EE certs defined so far (not counting router certs for = BGPSEC, which have yet to be agreed upon) are embedded in RPKI objects: = manifests, ROAs, and GB records. >=20 > A new manifest MUST be published whenever any file at a pub point = changes. The CPS template recommends daily CRL issuance, and that seems = to be what the RIRs are doing for the pub points that they maintain . = Thus it is likely that a new manifest will be issued every day. So, I = doubt that many manifest cert will be revoked. But when they are, you better get'm fast... If you're intended to play the "charter says .." card then we're wasting = our time. At least I've got my concerns on record for broader reference.. This is = unfortunate. -danny --Apple-Mail-1-564869998 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Nov 3, 2011, at 7:09 AM, Stephen = Kent wrote:

these obvious threats because the current charter = [deliberately] says 
all we have to do is provide = semantic validation of the AS_PATH" [and 
doing anything = more would quite possibly NOT be conducive to 
expedited = publication of BGPSEC].  

I = agree that the integrity that would result from including this attribute = under the sig applied by the first AS would provide the secruity you = cited. That may make it worthwhile to protect via the sig. However, the = accuracy of the assertion being made by this attribute is unverifiable = by any of the ASes along the path, and that was what worried me.  = But, again, the charter makes this out of scope, i.e., it is not = relevant to the origin authorization or path accuracy vulnerabilities = cited there.

NIce, another = threat that shouldn't be listed because it's not in the = charter 
as written or addressed via BGPSEC as is. =  If that's the case, then all the 
drafts should = include the current revision of the charter and explicit text = about 
ignoring all other threats under these = auspices.

It = is up to each RP to decide whether to rely on assertions made by an = expired cert, or to act as though the cert does not exist. In the = routing context, there appears to be some agreement that relying on = expired certs is more desirable
than treating the resources as = not certified. But, this is a per-RP = decision.

There is = only room for two states, right?  Valid and not valid.  Stale = =3D=3D not valid.

I = think the phrase "undermines the entire system" is melodramatic. How = about "you actual assurance may vary?" = :-)

"house of cards", = "village of cards"...

I = would prefer more centralization of RPKI data. My original model called = for each RIR to aggregate the data for every member, and act as a mirror = for the data for every other RIR. But other folks wanted greater = distribution. One can argue that wider distribution may offer = potentially greater resilience, so = ...

Yeah, I get it -- = until you get to the point where you have to use = expired 
certificates in a PKI and they may have been = revoked or may no longer 
be valid or intended for use = but because you can't pick certificates up 
from some = remote portion of the Internet then you relay on stale = (i.e., 
NOT valid) data.  Even if "more = distributed", I'm not sure that's added 
resilience, = particularly when PKI is employed.

 every RP needs to know the = revocation  status of everycert, OCSP (or an = analogous mechanism) does not seem to be a good match.  For many = years folks have thought that very fast dissemination of revocation = status data was important for PKIs.  In reality, revocation is an = administrative procedure for which the major delays will = be
created by people deciding whether to revoke a cert, vs. = the time it takes to disseminate the = CRL.

And I'm saying that = if we're going to employ a PKI solution on a = distributed 
loosely coherent resource certification = infrastructure that's going to be employed 
by RPs in a = non-determinsitc manner and result in "periodic updates" in = the 
routing system in order to minimize exposure = windows, then we ought to look 
at what architectural = approaches can be considered or what new = elements 
invented to minimize unneeded state and = churn in the network and maximize 
resiliency = without introducing the possibly for any array of new = attacks.

We've already seen issues where such = an approach has been problematic with 
DNSSEC in the wake = of portions of the Internet being fragmented and = causing 
issues and inability to update = certificates in the system at root, TLD and = SLD 
levels, and what you're proposing here is far = far more troubling.

All = of the EE certs defined so far (not counting router certs for BGPSEC, = which have yet to be agreed upon) are embedded in RPKI objects: = manifests, ROAs, and GB records.

A new manifest = MUST be published whenever any file at a pub point changes. The CPS = template recommends daily CRL issuance, and that seems to be what the = RIRs are doing for the pub points that they maintain . Thus it is likely = that a new manifest will be issued every day. So, I doubt that many = manifest cert will be = revoked.

But when they = are, you better get'm fast...

If you're = intended to play the "charter says .." card then we're wasting our = time.
At least I've got my concerns on record for broader = reference..  This is = unfortunate.

-danny

= --Apple-Mail-1-564869998-- From kent@bbn.com Thu Nov 3 08:58:10 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6870011E80D8 for ; Thu, 3 Nov 2011 08:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.495 X-Spam-Level: X-Spam-Status: No, score=-106.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbTG2aM2csfL for ; Thu, 3 Nov 2011 08:58:06 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4F31B11E8149 for ; Thu, 3 Nov 2011 08:58:04 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:40013 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RLzfs-0009wQ-F1; Thu, 03 Nov 2011 11:57:53 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> Date: Thu, 3 Nov 2011 11:43:12 -0400 To: Danny McPherson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 15:58:12 -0000 Danny, I'm reducing my reply to minimize what has become a tedious process. ... >The charter is temporal and the product of the WG in the form of RFCs >will be much more persistent, I'm concerned by a line of reasoning that >says "Let's ignore and not even enumerate or concern ourselves with >these obvious threats because the current charter [deliberately] says >all we have to do is provide semantic validation of the AS_PATH" [and >doing anything more would quite possibly NOT be conducive to >expedited publication of BGPSEC]. While I appreciate your concerns, comments from one WG member do not warrant changing the scope of a document to extend beyond the WG charter. When the charter changes, or upon direction of the WG chairs I will revise the doc. >... >And I'm saying that if we're going to employ a PKI solution on a distributed >loosely coherent resource certification infrastructure that's going >to be employed >by RPs in a non-determinsitc manner and result in "periodic updates" in the >routing system in order to minimize exposure windows, then we ought to look >at what architectural approaches can be considered or what new elements >invented to minimize unneeded state and churn in the network and maximize >resiliency without introducing the possibly for any array of new attacks. Feel free to propose such mechanisms. >We've already seen issues where such an approach has been problematic with >DNSSEC in the wake of portions of the Internet being fragmented and causing >issues and inability to update certificates in the system at root, TLD and SLD >levels, and what you're proposing here is far far more troubling. Can you point me to reports on those incidents. I have not heard about them. ... >If you're intended to play the "charter says .." card then we're >wasting our time. Yes, we are both wasting our time at this stage. Steve From kent@bbn.com Thu Nov 3 09:04:34 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7281F0C81 for ; Thu, 3 Nov 2011 09:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.386 X-Spam-Level: X-Spam-Status: No, score=-106.386 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9zz1yZn14rN for ; Thu, 3 Nov 2011 09:04:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id DBF0D1F0C7C for ; Thu, 3 Nov 2011 09:04:33 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:50240 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RLzmL-000A2S-3S; Thu, 03 Nov 2011 12:04:33 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> Date: Thu, 3 Nov 2011 11:59:07 -0400 To: Danny McPherson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 16:04:34 -0000 At 9:32 PM -0400 11/2/11, Danny McPherson wrote: >On Nov 2, 2011, at 11:04 AM, Stephen Kent wrote: >> The focus of BGPSEC is eBGP, because the concern is verifying the >> authenticity of routes arriving from other ASes. The hard problems arise >> for eBGP because these routes are delivered via BGP speakers in different >> "trust domains." iBGP integrity and authenticity can be achieved >>via internal security procedures and thus is not a focus of BGPSEC. > >But given that these attributes and the threat model include internal BGP >speakers and the largest scale issues (e.g., route reflectors with 5 millions >paths _today), we can't simply expect that it's out of scope. I think we can, because of the SIDR charter. The focus is on authenticity for inter-AS paths, not intra-AS paths. Any attacks against iBGP would appear, externally, to be equivalent to internal config errors or other forms of internal attacks. But, if you wish, I can add a sentence or two to state that explicitly. > > I replied to the ORIGIN attribute question in my other message. >> >> NLRI and AS_PATH are the attributes being protected both because >>they represent the fundamental routing data elements, and because >>they are attested to in the RPKI. Using the RPKI we can determine >>whether the origin AS is authorized to originate a route for the >>NLRI. We can verify whether a BGP speaker representing each AS in >>the AS_PATH is the entity that signed the data carried as part of >>an Update. We don't have analogous, authoritative data about MPLS, >>for example, so we can't provide the same sort of security >>guarantees. If the community identifies data carried in Updates >>that it believes should be protected, and >> we can agree on security semantics that are enforceable relative >>to the BGPSEC architecture, then we could expand protection, >>perhaps in a v2 of the protocol. > >But if we add considerable overhead (orders of magnitude from where we >are today) to deploy BGPSEC and only focus on a subset of the Path >Attribute (i.e., AS_PATH only) integrity functions then the ORIGIN code >Path Attribute (and also many others) can still be manipulated to change >BGP decision algorithms and induce traffic attraction attacks, then perhaps >we need to challenge the assumptions that led to scoping a solution to >AS_PATH and NLRI in the first place, as I really haven't seen a consensus >call on this in the WG either? The WG charter established this scope. >I think I constitute a participant in "the community" here -- or are we all >expected to accept this large set of documents and assumptions as gospel >and use the SIDR WG as a publication house for work done outside of the >IETF? I'd be less uncomfortable if the aim was to publish this set of >documents as Experimental until they generate some critical deployment >mass, and the broader community refines based upon operational experience >until then, which is something that I'm becoming more amenable to, but to >dictate as "the solution" for secure routing with some many outstanding issues >concerns me. see comment above. > > Beacon frequency affects how responsive BGPSEC is relative to one >set of attacks. A more accurate statement is that the beacon >parameters that the BGPSEC design is likely to use will induce >significant latency detecting those attacks. Reducing the latency >would require more frequent beaconing, and that is viewed as an >unacceptable tradeoff, at lest for now. The residual vulnerability >due to beacon latency relates to the ability of an AS that was >authorized to advertise a route, to replay the advertisement, even >when it is not currently authorized to do so. This vulnerability >should be viewed in the context of the inability of a BGP speaker to >know whether a neighbor has failed to withdraw a route, when it has >no paths for the prefix in question. An AS cannot, in general, know >whether the only route for a given prefix has been withdrawn at some >point upstream. This the BGP design and operational model embodies >this vulnerability. > >And to challenges assumptions, why is beaconing or the current mechanisms >proposed in BGPSEC the right approach -- surely it's something more >than "because >we bolted a PKI on to a distributed protocol and this is how it's >got to work? If that's >the case, this becomes a prime example of precisely why we don't want to bolt >security on after the fact, particularly in the case of distributed >systems and protocols, >and if we're working on 8-10 year out solutions, I'd like to think >we can do better than >this. I agree that adding security after the fact is never the preferred approach. But we often are forced to do that in the IETF because we have very widely deployed protocols. The IESG chartered this WG with a specific scope. We are adding onto BGP, not starting from scratch. You're certainly welcome to propose how to do this better, consistent with the SIDR charter. >More specifically, if I have perform a cost/benefit analysis it's >not at all clear to me >that tightening exposure windows to the frequency (hours/days) >you're suggesting >is worth the investment and fundamental shift from the stateful BGP >model we know >today, particularly given the drive-by and targeted nature we see in >all other aspects >of security today (e.g., APT, phishing, etc..). I presume that your statement "fundamental shift from the stateful BGP model..." refers to beaconing. Beaconing does create a new basis for propagating a route, but an AS could cause the same impact on the routing system by changing other route parameters at the same frequency, consistent with the BGP spec. I'd prefer a better solution, but I don't have one to offer at this time. Steve From paul.hoffman@vpnc.org Thu Nov 3 09:19:54 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4036A1F0C8B for ; Thu, 3 Nov 2011 09:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBIm78bfmOMW for ; Thu, 3 Nov 2011 09:19:53 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C93461F0C7C for ; Thu, 3 Nov 2011 09:19:53 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pA3GJqNS093267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 3 Nov 2011 09:19:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: Date: Thu, 3 Nov 2011 09:19:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> To: sidr wg list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 16:19:54 -0000 On Nov 3, 2011, at 8:43 AM, Stephen Kent wrote: >> If you're intended to play the "charter says .." card then we're = wasting our time. >=20 > Yes, we are both wasting our time at this stage. Maybe not. The charter does not say "every other topic cannot even be = mentioned": instead, the charter limits the topics that are meant to be = fully covered by the protocols. Personally, I would prefer to see the threat model document say in the = introduction "the following topics are considered to be BGP security = threats but are not dealt with in this document:" followed by a list = that includes route leakage (with a concise definition of what is meant = by it in this context). A similar statement in the Security = Considerations section would also be useful for the people who tend to = skip introductions but still need to know the limitations of the = document. --Paul Hoffman From warren@kumari.net Thu Nov 3 10:06:34 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FB211E8118 for ; Thu, 3 Nov 2011 10:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYOJI29338KW for ; Thu, 3 Nov 2011 10:06:33 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0AA11E8083 for ; Thu, 3 Nov 2011 10:06:33 -0700 (PDT) Received: from [192.168.0.105] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 0F3641B40187; Thu, 3 Nov 2011 13:06:31 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Thu, 3 Nov 2011 13:06:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6BE70B4B-E585-459D-ACCF-56B6F800E430@kumari.net> References: <20111031232022.26304.78773.idtracker@ietfa.amsl.com> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1084) Cc: "sidr@ietf.org list" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 17:06:34 -0000 On Oct 31, 2011, at 7:56 PM, Sriram, Kotikalapudi wrote: > In this revised version, we (authors) have made changes with careful = consideration=20 > of all the comments (mostly of editorial nature) received from Warren = and Randy. >=20 > http://www.ietf.org/mail-archive/web/sidr/current/msg03349.html > http://www.ietf.org/mail-archive/web/sidr/current/msg03306.html=20 > http://www.ietf.org/mail-archive/web/sidr/current/msg03305.html > http://www.ietf.org/mail-archive/web/sidr/current/msg03304.html=20 >=20 > We have also made many other edits throughout the doc to improve > clarity and readability. Thank you. I support this moving forward (which is just a formality, I supported it = before as well, this all just makes it (IMO) better).. W >=20 > Sriram > ________________________________________ >=20 > Title : Use Cases and Interpretation of RPKI Objects = for Issuers and Relying Parties > Author(s) : Terry Manderson > Kotikalapudi Sriram > Russ White > Filename : draft-ietf-sidr-usecases-03.txt > Pages : 30 > Date : 2011-10-31 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-usecases-03.txt =20= >=20 From wesley.george@twcable.com Thu Nov 3 10:33:04 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF9F1F0C81 for ; Thu, 3 Nov 2011 10:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.806 X-Spam-Level: X-Spam-Status: No, score=-0.806 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKTfNnQgxH9O for ; Thu, 3 Nov 2011 10:33:04 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 259371F0C7C for ; Thu, 3 Nov 2011 10:33:04 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,450,1315195200"; d="scan'208";a="293091955" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 03 Nov 2011 13:28:56 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Thu, 3 Nov 2011 13:33:03 -0400 From: "George, Wes" To: Paul Hoffman , sidr wg list Date: Thu, 3 Nov 2011 13:33:01 -0400 Thread-Topic: [sidr] BGPSEC Threat Model ID Thread-Index: AcyaRNoeqlDWewcGRbeS/menSTGrMAAA3inA Message-ID: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> In-Reply-To: <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 17:33:04 -0000 > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Paul Hoffman > the charter limits the topics that are meant to be > fully covered by the protocols. > > Personally, I would prefer to see the threat model document say in the > introduction "the following topics are considered to be BGP security > threats but are not dealt with in this document:" followed by a list [WEG] +1, or even have the document deal with them at least briefly, but be clear= that the current scope (or other limitations) makes it difficult to solve = them. Not to put words in Danny's mouth, but I think that there are two general c= oncerns being raised about this document and the -reqs document. The first, which is far easier to deal with, is that a document(s) that sho= uld be relatively solution-agnostic is being tailored to preselect/justify = an existing (though still nascent) solution based on the current charter sc= ope. It should be a full discussion of the problem space that leads to sele= ction and prioritization of the important problems to solve, acceptable ris= ks, etc. This then serves as a method to (design and) evaluate a solution, = whether there's only one, or whether there are multiples. I too find it a bit strange that we're doing things in the reverse order (o= r in parallel), as usually these sorts of docs are written because the solu= tion doesn't exist yet, and this helps to clearly articulate the problem sp= ace, rather than retroactively defining it. Am I missing something regardin= g the intent of these documents? The second is more a question of charter, and scope for the solution, which= is definitely limited by charter. However, having a more comprehensive doc= ument on threats and design requirements may indeed drive a review of the s= cope and charter, either because it brings to light additional consideratio= ns, or because those who actually need to implement the solution on their n= etworks have provided feedback that leads to a different conclusion. I'm not recommending that we analyze the problem forever, because a partial= solution that is deployable may indeed be better than a theoretical one th= at solves more problems, but never materializes (or at the very least takes= longer). But there is a balance point between those, and I'm not totally c= ertain we're at that equilibrium yet, regardless of the current charter. Th= ere have now been multiple folks expressing concerns over the costs (be the= y operational, capital, expense, etc) to implement vs the benefit based on = what risks are mitigated by the solution vs which are not and the exposure = that represents to one's chosen line of business, so there's some value in = having an eyes-wide-open discussion about it. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From shane@castlepoint.net Thu Nov 3 10:38:17 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7681F0CAD for ; Thu, 3 Nov 2011 10:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTpyCqZmi0-i for ; Thu, 3 Nov 2011 10:38:16 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id B8ADB1F0C7C for ; Thu, 3 Nov 2011 10:38:16 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 67561268063; Thu, 3 Nov 2011 11:38:16 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Thu, 03 Nov 2011 11:38:16 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=58731; data-bytes=0 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Shane Amante In-Reply-To: Date: Thu, 3 Nov 2011 11:38:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> To: sidr wg list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 17:38:17 -0000 On Nov 3, 2011, at 11:33 AM, George, Wes wrote: >> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf = Of >> Paul Hoffman >=20 >> the charter limits the topics that are meant to be >> fully covered by the protocols. >>=20 >> Personally, I would prefer to see the threat model document say in = the >> introduction "the following topics are considered to be BGP security >> threats but are not dealt with in this document:" followed by a list >=20 > [WEG] > +1, or even have the document deal with them at least briefly, but be = clear that the current scope (or other limitations) makes it difficult = to solve them. Another +1. > Not to put words in Danny's mouth, but I think that there are two = general concerns being raised about this document and the -reqs = document. > The first, which is far easier to deal with, is that a document(s) = that should be relatively solution-agnostic is being tailored to = preselect/justify an existing (though still nascent) solution based on = the current charter scope. It should be a full discussion of the problem = space that leads to selection and prioritization of the important = problems to solve, acceptable risks, etc. This then serves as a method = to (design and) evaluate a solution, whether there's only one, or = whether there are multiples. > I too find it a bit strange that we're doing things in the reverse = order (or in parallel), as usually these sorts of docs are written = because the solution doesn't exist yet, and this helps to clearly = articulate the problem space, rather than retroactively defining it. +1 > Am I missing something regarding the intent of these documents? >=20 > The second is more a question of charter, and scope for the solution, = which is definitely limited by charter. However, having a more = comprehensive document on threats and design requirements may indeed = drive a review of the scope and charter, either because it brings to = light additional considerations, or because those who actually need to = implement the solution on their networks have provided feedback that = leads to a different conclusion. > I'm not recommending that we analyze the problem forever, because a = partial solution that is deployable may indeed be better than a = theoretical one that solves more problems, but never materializes (or at = the very least takes longer). But there is a balance point between = those, and I'm not totally certain we're at that equilibrium yet, = regardless of the current charter. There have now been multiple folks = expressing concerns over the costs (be they operational, capital, = expense, etc) to implement vs the benefit based on what risks are = mitigated by the solution vs which are not and the exposure that = represents to one's chosen line of business, so there's some value in = having an eyes-wide-open discussion about it. +1 -shane > Thanks > Wes George >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Thu Nov 3 10:49:15 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3CD1F0CA4 for ; Thu, 3 Nov 2011 10:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eyQMubpPms5 for ; Thu, 3 Nov 2011 10:49:15 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 040F91F0C76 for ; Thu, 3 Nov 2011 10:49:15 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RM1Pc-000H6w-Fo; Thu, 03 Nov 2011 17:49:12 +0000 Date: Thu, 03 Nov 2011 18:49:11 +0100 Message-ID: From: Randy Bush To: "George, Wes" In-Reply-To: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Paul Hoffman , sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 17:49:15 -0000 hint: the reqs draft was based first on draft-ietf-rpsec-bgpsecrec-10. randy From eosterweil@verisign.com Thu Nov 3 10:49:48 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21DE1F0C40 for ; Thu, 3 Nov 2011 10:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-WZJu7gz4Jq for ; Thu, 3 Nov 2011 10:49:48 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id DE13F1F0CC0 for ; Thu, 3 Nov 2011 10:49:47 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP; Thu, 03 Nov 2011 10:49:47 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id pA3HnZKi005100; Thu, 3 Nov 2011 13:49:35 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.131.30.68]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 13:49:34 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Thu, 3 Nov 2011 13:49:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <16009560-0A2D-465C-9D5F-A4AA83D79AA5@verisign.com> References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 03 Nov 2011 17:49:34.0787 (UTC) FILETIME=[F2C3A130:01CC9A50] Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 17:49:49 -0000 On Nov 3, 2011, at 11:43 AM, Stephen Kent wrote: > Danny, >=20 > I'm reducing my reply to minimize what has become a tedious process. >=20 > ... >=20 >> The charter is temporal and the product of the WG in the form of RFCs >> will be much more persistent, I'm concerned by a line of reasoning = that >> says "Let's ignore and not even enumerate or concern ourselves with >> these obvious threats because the current charter [deliberately] says >> all we have to do is provide semantic validation of the AS_PATH" [and >> doing anything more would quite possibly NOT be conducive to >> expedited publication of BGPSEC]. >=20 > While I appreciate your concerns, comments from one WG member do not = warrant changing the scope of a document to extend beyond the WG = charter. When the charter changes, or upon direction of the WG chairs I = will revise the doc. So, I have been watching this thread and reading the interplay. Likely = many of us (but at the very least, I) have been waiting with baited = breath for answers to these issues, or at least a beginning to = discussions of follow-on work to address them. However, since there appears to be need for more than one person on = record: I also share these concerns. Fair? >=20 >> We've already seen issues where such an approach has been problematic = with >> DNSSEC in the wake of portions of the Internet being fragmented and = causing >> issues and inability to update certificates in the system at root, = TLD and SLD >> levels, and what you're proposing here is far far more troubling. >=20 > Can you point me to reports on those incidents. I have not heard about = them. >=20 > ... >=20 >> If you're intended to play the "charter says .." card then we're = wasting our time. >=20 > Yes, we are both wasting our time at this stage. Disagree. These are important issues, and it seems that some design = work needs to be done to address them. afaict, there are issues in the = design that may be exposing attack vectors. I can't see how claiming, = "we are both wasting our time at this stage," is an acceptable response. = These are real security threats that may exist if specifications are = minted as is. imho, they _must_ be addressed, not ignored. Eric= From Sandra.Murphy@cobham.com Thu Nov 3 11:07:38 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF4D11E811B for ; Thu, 3 Nov 2011 11:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jkWwLS0dCXj for ; Thu, 3 Nov 2011 11:07:36 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8339711E80DA for ; Thu, 3 Nov 2011 11:07:36 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id pA3I7IsN016254 for ; Thu, 3 Nov 2011 13:07:20 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id pA3I7HBK010217 for ; Thu, 3 Nov 2011 13:07:17 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0339.001; Thu, 3 Nov 2011 14:07:17 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: agenda posted Thread-Index: AcyaT+I2lctC7UimRS6nU+ieddH0wg== Date: Thu, 3 Nov 2011 18:07:16 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F602717E@Hermes.columbia.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.24] Content-Type: multipart/alternative; boundary="_000_24B20D14B2CD29478C8D5D6E9CBB29F602717EHermescolumbiaads_" MIME-Version: 1.0 Subject: [sidr] agenda posted X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 18:07:38 -0000 --_000_24B20D14B2CD29478C8D5D6E9CBB29F602717EHermescolumbiaads_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have posted an agenda from requests for time and from drafts with recent = activity to discuss. Please look at the agenda and tell me whether you think the time you are al= lotted is adequate. We are still considering a time slot change. We have firm offers for a cha= nge to Mon afternoon and a maybe for a slot for a 2 hr Tue afternoon. I'll= let you know if and when anything happens. If we do move all or part of our time, the order of sessions will change. = Some of those on the agenda have already requested that they be chosen for = an earlier week slot if possible. This timing issue should be settled soon. --Sandy --_000_24B20D14B2CD29478C8D5D6E9CBB29F602717EHermescolumbiaads_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have posted an agenda from requests for time and from drafts with = recent activity to discuss.

Please look at the agenda and tell me whether you think the time you are al= lotted is adequate.

We are still considering a time slot change.  We have firm offers for = a change to Mon afternoon and a maybe for a slot for a 2 hr Tue afternoon.&= nbsp; I'll let you know if and when anything happens.

If we do move all or part of our time, the order of sessions will change.&n= bsp; Some of those on the agenda have already requested that they be chosen= for an earlier week slot if possible.

This timing issue should be settled soon.

--Sandy



--_000_24B20D14B2CD29478C8D5D6E9CBB29F602717EHermescolumbiaads_-- From wesley.george@twcable.com Thu Nov 3 11:13:05 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7169711E812D for ; Thu, 3 Nov 2011 11:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.825 X-Spam-Level: X-Spam-Status: No, score=-0.825 tagged_above=-999 required=5 tests=[AWL=0.638, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqUC4FheMe8w for ; Thu, 3 Nov 2011 11:13:04 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 89BC211E811B for ; Thu, 3 Nov 2011 11:13:04 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,450,1315195200"; d="scan'208";a="293113610" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 03 Nov 2011 14:08:57 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Thu, 3 Nov 2011 14:13:04 -0400 From: "George, Wes" To: Randy Bush Date: Thu, 3 Nov 2011 14:13:02 -0400 Thread-Topic: [sidr] BGPSEC Threat Model ID Thread-Index: AcyaUOft5V0l21blQrqqENT5G5M8HQAAiJ/Q Message-ID: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Hoffman , sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 18:13:05 -0000 > From: Randy Bush [mailto:randy@psg.com] > > hint: the reqs draft was based first on draft-ietf-rpsec-bgpsecrec-10. > > randy [WEG] A useful thing to have noted in the document itself for us young whippersna= ppers, perhaps in the acknowledgements. I also note that there is good additional discussion in 4.1, 4.5, while the= reqs draft only includes the bulleted items. Cf. my email about including = more explicit performance envelope requirements. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From eosterweil@verisign.com Thu Nov 3 13:06:56 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E811F0C56 for ; Thu, 3 Nov 2011 13:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RSkR9xi5Yqc for ; Thu, 3 Nov 2011 13:06:56 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 75C811F0C35 for ; Thu, 3 Nov 2011 13:06:17 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP; Thu, 03 Nov 2011 13:06:55 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id pA3K67id010757; Thu, 3 Nov 2011 16:06:07 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.131.30.68]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 16:06:07 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Thu, 3 Nov 2011 16:06:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> References: To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 03 Nov 2011 20:06:07.0335 (UTC) FILETIME=[05E73F70:01CC9A64] Cc: "draft-ietf-sidr-algorithm-agility@tools.ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 20:06:56 -0000 On Nov 2, 2011, at 4:34 AM, Stephen Kent wrote: > At 6:29 PM -0700 11/1/11, Terry Manderson wrote: >> On 31/10/11 11:59 PM, "Stephen Kent" wrote: >>=20 >>=20 >>>>=20 >>>> I understand why you want to, but don't come to the same conclusion = as to >>>> the mechanism. >>>>=20 >>>> Is that really the IETF's job? >>>=20 >>> SIDR was tasked by the SEc ADs to develop an alg transition = architecture. >>> The authors believe that uniform milestones are necessary as part of >>> a credible plan. >>>=20 >>=20 >> Architecture, yes. Structured approach, yes. To both of those I = agree. >> Having the IETF define the dates when algorithms shift. I am not = convinced. >=20 > An architecture that ignores the need to have a global, uniform set of = milestones for transition phases is incomplete. Having a model that requires independent administrative entities (the CA = operators here) in the Internet to obey a traffic cop sounds a little... = hard to swallow (operationally). I also remain quite unconvinced. I = think this indicates that there is a misalignment in the design, not a = problem in the above question. >=20 >> >> Call me a dirty rotten cynic but I just don't see this operational = aspect of >> >> one or more running RPKI hierarchies as part of the IETF. Although = you can >>>> prove me wrong, and I'll concede to an already enacted example = where dates >>>> were set for some artifact. >>>=20 >>> We have to have two, parallel hierarchies to avoid a flag day. This >>> is not a situation where every CA can decide, locally, when to >>> transition, because the the alg change affect ALL RPs. >>=20 >> We are talking years. The overlap will be significant. And I disagree = - in >> this case every CA has to consciously decide - there may well be a = situation >> that a mid term operational impact requires an important CA in the = middle of >> the chain to delay. That then renders all dates specified in any RFC = next to >> meaningless. >=20 > Yes, we are talking years. No, it cannot be a local, per-CA decision, = because > the transition affects all RPs. I anticipate that the stakeholders, = CAs and RPs, will have the ability to comment on the proposed dates, and = that the IETF/IESG will take into account these comments when developing = the timeline. If a major problem arises that makes it infeasible for CAs = to adhere t the timeline, a new RFC can be issued. So, to make sure I understand: if operational issues arise that cause an = independent administrative entity (one of the CA operators) to need to = delay an operational action, they need to get an RFC published? I must = have misunderstood? Eric= From danny@tcb.net Thu Nov 3 14:09:02 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806171F0CB6 for ; Thu, 3 Nov 2011 14:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnFqy2TtPJZq for ; Thu, 3 Nov 2011 14:09:02 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id B8FD21F0C76 for ; Thu, 3 Nov 2011 14:09:01 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 62013268063; Thu, 3 Nov 2011 15:09:01 -0600 (MDT) Received: from dul1dmcphers-m1.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 03 Nov 2011 15:09:01 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=59841; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-5-597364855 From: Danny McPherson In-Reply-To: Date: Thu, 3 Nov 2011 17:07:44 -0400 Message-Id: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> To: Stephen Kent X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 21:09:02 -0000 --Apple-Mail-5-597364855 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 3, 2011, at 11:43 AM, Stephen Kent wrote: > Can you point me to reports on those incidents. I have not heard about = them. I could cite others, but this should serve the purpose: Consider this and assume operators had infrastructure (e.g., root & TLD=20= servers) that was serving signed zones that couldn't be updated and = expired while partitioned from the rest of the Internet. The result is that = validating=20 recursive name servers within that catchment couldn't validate the = received responses, and they were therefore not valid and not able to resolve=20 resources. Designing a system so reliant on heavy cryptography machinery, but then=20= saying "just use expired certificates if you can't update your caches", = that's=20 crazy talk that would likely violate most of our day job security = policies for=20 even SSL or VPN access policies -- and here we want to apply it to a = newly=20 enhanced routing protocol and resource certification infrastructure --- = I=20 challenge that assumption. =20 And on further reflection, I think recommending that expired = certificates=20 be used (even in algorithm rollovers, presumably for the purpose of = fixing cryptographic vulnerabilities) may well NOT be aligned with our two = primary=20 charter objectives: * Is an Autonomous System (AS) authorized to originate an IP prefix=20 * Is the AS-Path represented in the route the same as the path through=20= which the NLRI traveled=20 I intend to ask the security ADs for a statement on suitably of use for=20= expired certificates, and would appreciate such an explanation from the SIDR technical advisor as well as the chairs at the upcoming meeting. -danny --Apple-Mail-5-597364855 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Can you point = me to reports on those incidents. I have not heard about = them.

I could cite others, but = this should serve the purpose:


Consider this and assume operators had = infrastructure (e.g., root & TLD 
servers) that was = serving signed zones that couldn't be updated and = expired
while partitioned from the rest of the Internet. =  The result is that validating 
recursive = name servers within that catchment couldn't validate the = received
responses, and they were therefore not valid and not = able to = resolve 
resources.

Designing a = system so reliant on heavy cryptography machinery, but = then 
saying "just use expired certificates if you can't = update your caches", that's 
crazy talk that would likely = violate most of our day job security policies for 
even = SSL or VPN access policies -- and here we want to apply it to a = newly 
enhanced routing protocol  and resource = certification infrastructure --- I 
challenge that = assumption.  

And on further reflection, I = think recommending that expired = certificates 
be used (even in algorithm rollovers, = presumably for the purpose of fixing
cryptographic = vulnerabilities) may well NOT be aligned with our two = primary 
charter objectives:

* Is an Autonomous System (AS) authorized to originate an IP prefix
* Is the AS-Path represented in the route the same as the path through
which the NLRI traveled 

I intend to ask the = security ADs for a statement on suitably of use = for 
expired certificates, and would appreciate such an = explanation from the
SIDR technical advisor as well as the = chairs at the upcoming = meeting.

-danny


= --Apple-Mail-5-597364855-- From terry.manderson@icann.org Thu Nov 3 17:49:15 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0D211E80C2 for ; Thu, 3 Nov 2011 17:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJdaVZdVAHWZ for ; Thu, 3 Nov 2011 17:49:14 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id CAFB611E80BF for ; Thu, 3 Nov 2011 17:49:14 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 3 Nov 2011 17:49:14 -0700 From: Terry Manderson To: Stephen Kent Date: Thu, 3 Nov 2011 17:49:12 -0700 Thread-Topic: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 Thread-Index: AcyZPPQVh/LIpqbdTca8uS+/+fMmRgBTp15e Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-sidr-algorithm-agility@tools.ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 00:49:15 -0000 On 2/11/11 6:34 PM, "Stephen Kent" wrote: >>=20 >> Architecture, yes. Structured approach, yes. To both of those I agree. >> Having the IETF define the dates when algorithms shift. I am not convinc= ed. >=20 > An architecture that ignores the need to have a global, uniform set > of milestones for transition phases is incomplete. I appreciate your view Steve. And in the traditional sense you are correct, unfortunately I think that level of completion, as a standards document, will be the 'enemy of the good' as that flips right over into operational space. >=20 > Yes, we are talking years. No, it cannot be a local, per-CA decision, bec= ause > the transition affects all RPs. I anticipate that the stakeholders, > CAs and RPs, will have the ability to comment on the proposed dates, > and that the IETF/IESG will take into account these comments when > developing the timeline. If a major problem arises that makes it > infeasible for CAs to adhere t the timeline, a new RFC can be issued. If you are that desperate to see this in play, then perhaps SIDR should consider creating an operational BCP that provides the recommendation for algorithms phase-in/phase-out dates. And in that comes the warning, that IETF specified dates (except for past events) are in a very grey area WRT the IETF. But neither this document (in blessing the idea) nor draft-ietf-sidr-rpki-algs (as standards track) is the place for it. >=20 >=20 >> What I do like about the document is the pre-canned phases, of what happ= ens >> when, and how. This is good.. and I think that satisfies the request fro= m >> the SEC ADs, but specifying the "when" in IETF - I just don't buy. >=20 > So, who do you propose as alternates? Your comment above about > parent(s) and "non-leaf" CAs issuing a statement encompasses IANA, > the RIRs, and thousands of ISPs. When has that set of players issued > a statement analogous to this? Surely the ISPs would be represented by or through the RIRs? I'm not an expert in communications between IANA/ICANN/RIRs but if they needed to issue a statement based on stakeholder (RP) consultation for 'the good of the internet', its likely they would. Cheers Terry From furry13@gmail.com Thu Nov 3 18:57:08 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA41A11E80AE for ; Thu, 3 Nov 2011 18:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vr7FVxcMnmT9 for ; Thu, 3 Nov 2011 18:57:08 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id E65AF11E8089 for ; Thu, 3 Nov 2011 18:57:07 -0700 (PDT) Received: by faas12 with SMTP id s12so2585037faa.31 for ; Thu, 03 Nov 2011 18:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QJ6O2W/qE44/3ovKvZp10DaVOV2htVcU4tv3VsKTvNE=; b=U0A/teGTNiO+XV/g6EHNDuJaZ/zPRTPWuII1Oqg7FWmRcTiguEL6zsrtDiYl2AxAoE NnAoNIaeANNZOkslt3V7vSfcUJaDqnskcAePYxLggPzr1CfbPuQQDq7ogWdQ1v8h6Ktt v10mlt0LOm/bVLXTLGnPBRvACEy+J9DVfvoCs= MIME-Version: 1.0 Received: by 10.223.62.209 with SMTP id y17mr20264428fah.7.1320371827039; Thu, 03 Nov 2011 18:57:07 -0700 (PDT) Received: by 10.223.101.136 with HTTP; Thu, 3 Nov 2011 18:57:06 -0700 (PDT) In-Reply-To: <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> Date: Fri, 4 Nov 2011 12:57:06 +1100 Message-ID: From: Jen Linkova To: Paul Hoffman , kent@bbn.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 01:57:08 -0000 Hi, On Fri, Nov 4, 2011 at 3:19 AM, Paul Hoffman wrote: > Maybe not. The charter does not say "every other topic cannot even be men= tioned": instead, the charter limits the topics that are meant to be fully = covered by the protocols. > > Personally, I would prefer to see the threat model document say in the in= troduction "the following topics are considered to be BGP security threats = but are not dealt with in this document:" followed by a list that includes = route leakage (with a concise definition of what is meant by it in this con= text). A similar statement in the Security Considerations section would als= o be useful for the people who tend to skip introductions but still need to= know the limitations of the document. First of all, sorry to butt in. Just a few comments if you don't mind. 0) There are some security issues with BGP. (Sorry for making such commonplace remark); then: 1) BGPSEC offers countermeasures for some BGP-specific threats mentioned above (! not all of them indeed) but: 2) it also introduces some additional new threads (specific to BGPSEC); 3) after reading this thread (please excuse me if I missed smth) I got an impression that there is a kind of confusion about if the document in question shall describe #1, #2, #3 or all of them. Probably it should be clarified. 4) I might be horribly wrong but route leaks is a security thread as it affects an availability of a target system (providing we define information security as confidentiality, integrity and availability of information). 5) I totally agree that route leaks don't violate BGP as a protocol and are related to policies. But it doesn't mean route leaks are not security threats. Receiving spam/viruses via email is a threat although it doesn't violate any SMTP standards. 6) route leaking is related to a BGP threat model and isn't specific to BGPSEC, and BGPSEC doesn't provide any protection from that threat. So I'd like to second the idea of clarifying that in the document. --=20 SY, Jen Linkova aka Furry From christopher.morrow@gmail.com Thu Nov 3 21:49:49 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5216421F9050 for ; Thu, 3 Nov 2011 21:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.52 X-Spam-Level: X-Spam-Status: No, score=-103.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exm5bNzLOB-T for ; Thu, 3 Nov 2011 21:49:48 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1F121F8F2F for ; Thu, 3 Nov 2011 21:49:48 -0700 (PDT) Received: by iaeo4 with SMTP id o4so2733861iae.31 for ; Thu, 03 Nov 2011 21:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+ACN7dpVkVfI+4cG1dDP0QQPg0N+U+wvU8pw0VZfEp8=; b=X6DmOdjo4ig1AhNtaKST4jbbn7BCLrFKjAKKGVIFg1HcxEaU0HjCkapHAdJKEPQugp fzU9edS2tAeC7A5sXEkwgAMllLciNUu4z/ricEnA31Snx/cgj58AXp304t0RbPj3fBx3 nwVFC7twBpa9fxqhC5sdKC7Zp9REKSEDFX5GA= MIME-Version: 1.0 Received: by 10.231.68.20 with SMTP id t20mr3022570ibi.18.1320382187871; Thu, 03 Nov 2011 21:49:47 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Thu, 3 Nov 2011 21:49:47 -0700 (PDT) In-Reply-To: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <4EB170AD.1030302@riw.us> Date: Fri, 4 Nov 2011 00:49:47 -0400 X-Google-Sender-Auth: tOlTkiQajScNB9GZE2R8gzWuA0I Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 04:49:49 -0000 (coming in late to the party, weee!) On Wed, Nov 2, 2011 at 1:08 PM, Brian Dickson wrote: >>> (5) If any BGP path attribute used in Path Selection is not signed, >>> then BGPSEC has failed to meet its charter requirements. >> >> Then MED and Local Pref must also be signed, along with a number of >> communities, and even the next hop. > > Yes. err, so... you receive a route update from AS1 at AS2, it looks roughly like: 1.2.3.0/24 nh = 192.168.1.1 this is signed (all of the above data) When you pass this route off to AS3 you do so as: 1.2.3.0/24 nh = 10.1.1.1 the nh changed, the sig originally is for 192.168.1.1 Did you really mean to sign the next-hop? it seems infeasible... Also, LocalPref is a locally used/determined/created (non-transitive) item, adding that set of bits into the signature seems blatantly wrong, since the data won't exist when you pass the route outside your ASN the verification is going to fail, for every route you send (which had a localpref != default), That CERTAINLY seems like something you would want to avoid, right? -chris From jakob.heitz@ericsson.com Thu Nov 3 22:18:19 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C7E1F0C41 for ; Thu, 3 Nov 2011 22:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.628 X-Spam-Level: X-Spam-Status: No, score=-5.628 tagged_above=-999 required=5 tests=[AWL=0.971, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfGWY4IsI6RO for ; Thu, 3 Nov 2011 22:18:18 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id B4EF11F0C3D for ; Thu, 3 Nov 2011 22:18:18 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pA45I1qJ017100; Fri, 4 Nov 2011 00:18:10 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.52]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 4 Nov 2011 01:18:03 -0400 From: Jakob Heitz To: Brian Dickson , Stephen Kent Date: Fri, 4 Nov 2011 01:18:01 -0400 Thread-Topic: Route Leak fix: V free routing Thread-Index: AcyY6i6XGiiG7294R6+FEKAHa5c26ABrfPzg Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A447FBB8F@EUSAACMS0701.eamcs.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: [sidr] Route Leak fix: V free routing X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 05:18:19 -0000 I had a different idea. Model the internet as providers, customers and peers. A provider is above you, a customer is below you and a peer is level to you. Add a "down" bit to the BGPSEC signature block. If an AS sends an update to a customer, it sets the "down" bit. The rule is "V" free routing. Once an update goes "down", it can not come back "up". Sending to peers is always ok. If an AS receives from a customer an update that has a "down" bit in the BGPSEC attribute, it will detect the update as a route leak. Policy will dictate how to deal with it. An AS sets the "down" bit to indicate its wish that the announced prefix stay within the customer's bounds. As it is signed, it can not be changed further down the path. --=20 Jakob Heitz. On Tuesday, November 01, 2011 4:01 PM, Brian Dickson <> wrote: > Upon further consideration, in the interest of not revealing > information that is currently not revealed in BGP, I'll suggest > modifying my earlier proposal as follows: > - the proposed flag needs to exist and be signed by the sender, but > only the last instance of the flag is carried with the route. > - the enforcement of not-promote still needs to be done by the > protocol=20 > - the route will only have the "transit" bit on a per-route basis, of > the last AS (regardless of where demotion occurred, if at all) > - the receiver of a route with the "transit" bit set will generally > already be aware that the receiver is providing transit service, if > legitimately set >=20 > Otherwise, everything else still stands to reason... >=20 > Brian >=20 > On Tue, Nov 1, 2011 at 6:45 PM, Brian Dickson > wrote: >> I have a proposal, to address the route-leak issue. It necessarily >> requires changes to all of the following documents, if it is adopted: >> - threat model >> - protocol >> - requirements >> - NB: this proposed element does not have a corresponding value in >> vanilla BGP.=20 >> - (If BGP had this already, there would not be any route leaks.) >>=20 >> Here is what I propose: >> Add an announced Path Attribute, "Transit", to every BGPSEC signature >> block on an announced prefix. >> "Transit" is a flag bit, and applies to the _announcement_ between >> ASNs in the path. >> Include this Transit flag in the set of things that are signed. >> Make this attribute mandatory to BGPSEC, applied to every signature >> block on a route. >>=20 >> Every BGPSEC peering session is either Transit, or Not-Transit, from >> the perspective of the local AS. >>=20 >> For BGPSEC speakers A and B, all four combinations are legitimate >> scenarios:=20 >> A and B are "strictly speaking, peers" - e.g. 'tier-1' networks A >> and B:=20 >> - A->B is "not-transit" >> - B->A is "not-transit" >> A provides transit to B (or vice versa; exchange labels A and B): >> - A->B is "not-transit" >> - B->A is "transit" >> A and B provide "mutual backup transit": >> - A->B is "transit" >> - B->A is "transit" >>=20 >> The last scenario *should* be extremely rare. The last scenario >> happens to also be the default behavior >> for BGP when unconstrained routing announcements exist, i.e. >> inexperienced network engineers are >> given "enable" and asked to "do BGP". >>=20 >> Here are the specific details and semantics, that in general make >> "the=20 >> right thing" happen, and stop >> route leaks from happening, whether by accident or design. >>=20 >> 1) The "transit" bit can be demoted to "not-transit" (on received, >> signed BGPSEC routes). >> 2) The "transit" bit cannot be promoted from "not-transit" to >> "transit" (on received, signed BGPSEC routes). >> 3) Routes can be originated as "transit" or "not-transit". The >> sensible default behavior is "transit". >> 4) Routes that are received, under a default configuration, SHOULD be >> demoted to "non-transit". >> 4a) Transit ISPs MUST change the (default) configuration on their >> customers' BGP sessions to not-demote their customers' routes. >> 4b) Mutual-Transit arrangements MUST change the (default) >> configuration to not-demote their respective routes. >> 5a) A route with the "transit" bit MAY be sent over any BGPSEC >> peering session. 5b) A route received with the "transit" bit set MAY >> be accepted by the receiver. 6a) A route with the "transit" bit not >> set (i.e. a not-transit route)=20 >> MAY NOT be sent over a peering session that does not permit "transit" >> routes in unmodified (i.e. a peering session that demotes to >> not-transit). >> 6b) A route with the "transit" bit not set (i.e. a non-transit route) >> MAY ONLY be accepted over a peering session configured to send >> "transit" routes (i.e. an "upstream" peer). >>=20 >> If this logic is implemented in the PROTOCOL, and outside of user >> configuration control >> (i.e. limiting user control to "not-demote" and "send-transit"), >> route leaks cannot happen, or at worst have a scope >> of the next local AS if the _receiver_ makes a configuration error. >>=20 >> That is to say, route leaks become, at worst, non-transitive. >>=20 >> Here's a summary of how and why: >> Not-transit (peer) routes can only be sent "downstream", >> where "downstream" can include mutual-transit links. >> Transit routes can be sent everywhere, but only retain >> their "transit" bits when _both_ the sender _and_ receiver agree >> that the link is a transit link. >>=20 >> As soon as a route loses its "transit" bit, it can never regain it, >> whether by accident or design. >>=20 >> Note the following: >> - "Transit" or "not-Transit" is applied on the sender side of >> peering.=20 >> Default is "Transit". >> - "Demote" or "not-Demote" is applied on the receiver side of >> peering.=20 >> Default is "Demote". >> - The originator of a route sets "Transit". >> - "Transit" on a sender-side really means "Do not demote this on >> send".=20 >> - Thus, a sender with "Transit" configured, will never _promote_ a >> non-transit route to transit. >> - And thus, a receiver will automatically filter out >> "non-transit"-marked routes from a combined >> =A0set of routes that includes "transit" and "not-transit", if only >> "transit" are allowed (e.g. an upstream ASN) >>=20 >> [The original motivating discussion follows...] >>=20 >> On Tue, Nov 1, 2011 at 9:57 AM, Stephen Kent wrote: >>> At 4:20 PM -0400 10/29/11, Danny McPherson wrote: >>>=20 >>> Some comments on sidr-bgpsec-threats-00 below.. >>>=20 >>> Most substantial of my concerns is Section 5's "Residual >>> Vulnerabilities", specifically: >>>=20 >>> =A0"BGPSEC has a separate set of residual vulnerabilities: >>>=20 >>> =A0 - BGPSEC is not able to prevent what is usually referred to as >>> =A0=A0=A0 route leaks, because BGP itself does not distinguish between >>> =A0=A0=A0 transit and non-transit ASes- >>=20 >> This is a chicken-and-egg issue. Since there are several documents >> before=20 >> the WG, some of which have not yet even been accepted by the WG, it >> is premature to say what BGPSEC does and does not do. >>=20 >> We are (in this WG) collectively defining what BGPSEC does and does >> not do.=20 >> The real question is, fundamentally, are there unavoidable >> limitations that make it impossible for BGPSEC to do particular >> things?=20 >>=20 >>> Do we really consider it acceptable that the solution and machinery >>> we're recommending will NOT prevent "route leaks", >>=20 >> IMHO, "No". Frankly, I consider fixing the route leak problem >> non-negotiable. We can and must fix it. It hasn't been fixed in BGP, >> because there has=20 >> always been the >> ability to mess with transitive attributes. Without enforcement, it >> can't truly be fixed. >>=20 >> Since BGPSEC is solving the attribute-tampering problem, the >> practical realities that enabled route leaks, no longer strictly >> exist (within a BGPSEC realm). Which means, we can stop route leaks. >>=20 >> I argue that, because we can, now, we MUST. >>=20 >>> Route leaks represent a violation of an ISPs local policy, i.e., >>> the ISP is propagating routes that it, locally, did not intend to >>> propagate. There is no semantic in BGP that captures this aspect of >>> local policy.=20 >>=20 >> Actually, no. Route leaks represent both a violation of a BGP >> speaker's intended local policy, *and* a violation of other BGP >> speakers' intended policies.=20 >>=20 >> There is nothing that prevents the addition of this new semantic >> (single bit) alongside signatures, >> and in particular within the signed data, which unequivocably >> establishes this intent. >>=20 >> By signing the intent, it becomes globally known as well as locally >> significant. And by being signed, it is tamper-evident. Rejecting >> tampered paths,=20 >> or de-prefering >> tampered paths, eliminates route leaks. >>=20 >> Problem solved (IMNSHO). >>=20 >> Brian >>=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From brian.peter.dickson@gmail.com Thu Nov 3 22:32:22 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7376911E808D for ; Thu, 3 Nov 2011 22:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idpCIlsyIKZo for ; Thu, 3 Nov 2011 22:32:21 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E57111E8081 for ; Thu, 3 Nov 2011 22:32:21 -0700 (PDT) Received: by faas12 with SMTP id s12so2713651faa.31 for ; Thu, 03 Nov 2011 22:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ngFptfSZfaulezZJw7lbTD4RAmraj8hd1t7Jsw3SwOA=; b=Y0QHxdfWoGP+qadY1QTfkkcvTVTso/nfGuZArUw5BJ6B7ZLDnDM/4daKUJTcuVNKnQ ADK5sqQIPTrp0fripbhwtLylaij8nhtFUtrhc7GGsLgGpKVmU58Kn8setGciOATL+o6a 4YXxCFH61spWHmRWqazPz0WrqgzhzvyHKtbCo= MIME-Version: 1.0 Received: by 10.223.76.27 with SMTP id a27mr21681983fak.12.1320384740462; Thu, 03 Nov 2011 22:32:20 -0700 (PDT) Received: by 10.223.54.15 with HTTP; Thu, 3 Nov 2011 22:32:20 -0700 (PDT) In-Reply-To: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <4EB170AD.1030302@riw.us> Date: Fri, 4 Nov 2011 01:32:20 -0400 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 05:32:22 -0000 On Fri, Nov 4, 2011 at 12:49 AM, Christopher Morrow wrote: > (coming in late to the party, weee!) > > On Wed, Nov 2, 2011 at 1:08 PM, Brian Dickson > wrote: >>>> (5) If any BGP path attribute used in Path Selection is not signed, >>>> then BGPSEC has failed to meet its charter requirements. >>> >>> Then MED and Local Pref must also be signed, along with a number of >>> communities, and even the next hop. >> >> Yes. > > err, so... you receive a route update from AS1 at AS2, it looks roughly l= ike: > =A0 1.2.3.0/24 nh =3D 192.168.1.1 > =A0this is signed (all of the above data) > > When you pass this route off to AS3 you do so as: > =A0 1.2.3.0/24 nh =3D 10.1.1.1 > =A0the nh changed, the sig originally is for 192.168.1.1 > > Did you really mean to sign the next-hop? it seems infeasible... > > Also, LocalPref is a locally used/determined/created (non-transitive) > item, adding that set of bits into the signature seems blatantly > wrong, since the data won't exist when you pass the route outside your > ASN the verification is going to fail, for every route you send (which > had a localpref !=3D default), That CERTAINLY seems like something you > would want to avoid, right? Er, on non-transitive items like LocalPref, there is a use case for signing them iff the iBGP elements are decided as being in-scope. (I agree with Danny on this being worth considering.) What we are discussing is the threat model, and how threats could be countered. This in turn is used to inform the design of the protocol, not vice versa. So, when I say "signed", what I was thinking of was something along the lin= es of a sequence of blocks that might look something like: LocalBGPPerHopData signature(LocalBGPPerHopData|previousSignature) and after all those blocks, originatorSignature(FirstHopData|RPKI-validatable-data) The stack gives a history of transitive and non-transitive values, some of which won't be used for local policy decisions per se, and some of = which can quite reasonably have been changes at each hop. The signatures protect that data. How the protected data itself is used is local policy, for selecting best p= ath. This is more information than vanilla BGP has, of course, but arguably allo= ws for better path selection by virtue of more data being available locally. Note that nothing is present than is generally known through various data sources, including local BGP tables, looking glasses, routeviews/Renesys, traceroute= s, whois, RADB/IRR, RIRs, reverse DNS etc. Adding this "stack" allows for other aspects of local policy to be marked into the path, including markers suitable for preventing route leaks. It also means that non-transitive values can magically become pseudo-transi= tive, presuming the cruft that permits constructing local policy can be made to understand the association between AS-path hops and the captured policy at those hops. (This is a feature, not a bug.) The signatures make it possible to reject changes to this stack of path-historical data. The data makes it possible to choose to use the originated values, the latest values, or anything in between, however one chooses. The requirements to continue adding to this stack ensures the next AS to which the prefix is sent, has the same opportunity to apply local policy. Add a dollop of 'transit/non-transit' at each hop (mandatory but arbitrary), and simple leak-blocking (nearly fool-proof, in fact) is possible to support. Brian From randy@psg.com Fri Nov 4 01:09:24 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A096121F8B16 for ; Fri, 4 Nov 2011 01:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvxVvpNRym53 for ; Fri, 4 Nov 2011 01:09:24 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 370CC21F8AEC for ; Fri, 4 Nov 2011 01:09:24 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RMEq1-000Iua-Ua; Fri, 04 Nov 2011 08:09:22 +0000 Date: Fri, 04 Nov 2011 09:09:20 +0100 Message-ID: From: Randy Bush To: Brian Dickson In-Reply-To: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <4EB170AD.1030302@riw.us> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 08:09:24 -0000 > Er, on non-transitive items like LocalPref, there is a use case for > signing them iff the iBGP elements are decided as being in-scope. (I > agree with Danny on this being worth considering.) send draft randy From randy@psg.com Fri Nov 4 01:11:14 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FC321F8BF4 for ; Fri, 4 Nov 2011 01:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDtHUyZa1Jzw for ; Fri, 4 Nov 2011 01:11:14 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id EA20621F8AEC for ; Fri, 4 Nov 2011 01:11:13 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RMErp-000Iv2-Gg; Fri, 04 Nov 2011 08:11:13 +0000 Date: Fri, 04 Nov 2011 09:11:11 +0100 Message-ID: From: Randy Bush To: Jen Linkova In-Reply-To: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 08:11:14 -0000 > 5) I totally agree that route leaks don't violate BGP as a protocol > and are related to policies. But it doesn't mean route leaks are not > security threats. Receiving spam/viruses via email is a threat > although it doesn't violate any SMTP standards. > > 6) route leaking is related to a BGP threat model and isn't specific > to BGPSEC, and BGPSEC doesn't provide any protection from that threat. > So I'd like to second the idea of clarifying that in the document. could someone post a clear technical explanation of WHAT a route leak is, HOW one would definitively detect all cases of them, and WHAT one would do about it? you are correct, BGPsec tries to secure the BGP protocol against abuse, not protect the internet. the latter is a very worthy goal but a bit nebulous. of course an internet draft or two might clarify that. randy From kent@bbn.com Fri Nov 4 02:02:49 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69BA21F8C1E for ; Fri, 4 Nov 2011 02:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.503 X-Spam-Level: X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjlrB7txMf9Q for ; Fri, 4 Nov 2011 02:02:49 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id DED2221F8BFB for ; Fri, 4 Nov 2011 02:02:48 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:56623 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RMFfj-0008rK-6h; Fri, 04 Nov 2011 05:02:47 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 4 Nov 2011 04:56:51 -0400 To: Terry Manderson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "draft-ietf-sidr-algorithm-agility@tools.ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 09:02:49 -0000 At 5:49 PM -0700 11/3/11, Terry Manderson wrote: >On 2/11/11 6:34 PM, "Stephen Kent" wrote: > >>> >>> Architecture, yes. Structured approach, yes. To both of those I agree. >>> Having the IETF define the dates when algorithms shift. I am not convinced. >> >> An architecture that ignores the need to have a global, uniform set >> of milestones for transition phases is incomplete. > >I appreciate your view Steve. And in the traditional sense you are correct, >unfortunately I think that level of completion, as a standards document, >will be the 'enemy of the good' as that flips right over into operational >space. One of the initial set of SIDR RFCs is draft-ietf-sidr-rpki-algs. The new alg suite will be defined in a new version of that doc. I envisioned that this doc would also be the place where the milestones will be published. But, a BCP specifying the milestones seems reasonable as well. > > Yes, we are talking years. No, it cannot be a local, per-CA >decision, because > > the transition affects all RPs. I anticipate that the stakeholders, >> CAs and RPs, will have the ability to comment on the proposed dates, >> and that the IETF/IESG will take into account these comments when >> developing the timeline. If a major problem arises that makes it >> infeasible for CAs to adhere t the timeline, a new RFC can be issued. > >If you are that desperate to see this in play, then perhaps SIDR should >consider creating an operational BCP that provides the recommendation for >algorithms phase-in/phase-out dates. And in that comes the warning, that >IETF specified dates (except for past events) are in a very grey area WRT >the IETF. I think the BCP idea is appropriate. I don't agree with your gray area argument. Let's avoid terms like "desperate." >But neither this document (in blessing the idea) nor >draft-ietf-sidr-rpki-algs (as standards track) is the place for it. let's just say we disagree, modulo the idea of putting the milestones in a BCP. > >> What I do like about the document is the pre-canned phases, of >what happens > >> when, and how. This is good.. and I think that satisfies the request from >>> the SEC ADs, but specifying the "when" in IETF - I just don't buy. >> >> So, who do you propose as alternates? Your comment above about >> parent(s) and "non-leaf" CAs issuing a statement encompasses IANA, >> the RIRs, and thousands of ISPs. When has that set of players issued >> a statement analogous to this? > >Surely the ISPs would be represented by or through the RIRs? > >I'm not an expert in communications between IANA/ICANN/RIRs but if they >needed to issue a statement based on stakeholder (RP) consultation for 'the >good of the internet', its likely they would. In principle the RIRs & IANA, perhaps the NRO & IANA, would be an appropriate group to issue such a statement. So far, this process has been rocky, which is probably why there is an IAB-issused statement re IANA as a global TA for the RPKI. Nonetheless, this might be a reasonable split of responsibility, i.e., alg spec through the IETF process, and milestone publication via an RFC authored by the NRO and IANA. Steve From kent@bbn.com Fri Nov 4 02:03:12 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F47B21F8C2F for ; Fri, 4 Nov 2011 02:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.506 X-Spam-Level: X-Spam-Status: No, score=-106.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqI2wmZ8S0+M for ; Fri, 4 Nov 2011 02:03:11 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 581E921F8BFB for ; Fri, 4 Nov 2011 02:03:11 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:56623 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RMFfg-0008rK-MB; Fri, 04 Nov 2011 05:02:45 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> References: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> Date: Fri, 4 Nov 2011 04:45:59 -0400 To: Eric Osterweil From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "draft-ietf-sidr-algorithm-agility@tools.ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 09:03:12 -0000 Eric, 1- Yes, there is a need for global coordination for alg transition, under the design presented. If you have an alternative proposal, please share it. This design was originally documented in June, 2010, in an individual I-D authored by me. It has been briefed at several SIDR WG meetings, starting at IETF 78 in July, 2010. This is not new. 2- Not exactly. The milestones, as well as the alg suite spec, will appear in a revised version of draft-ietf-sidr-rpki-algs. Any operational problem that requires a delay in any transition phase would be brought to the attention of the IESG (if the SIDR WG is no longer active) requesting that a this RFC be re-issued, with new milestone values for the affected phase(s). Steve From kotikalapudi.sriram@nist.gov Fri Nov 4 06:02:44 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A4121F8C11 for ; Fri, 4 Nov 2011 06:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jv1qJAyJFqsx for ; Fri, 4 Nov 2011 06:02:43 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id A3A2621F8BEC for ; Fri, 4 Nov 2011 06:02:43 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 4 Nov 2011 09:02:33 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 4 Nov 2011 09:02:41 -0400 From: "Sriram, Kotikalapudi" To: Brian Dickson Date: Fri, 4 Nov 2011 09:02:08 -0400 Thread-Topic: [sidr] BGPSEC Threat Model ID Thread-Index: AcyasxCWYHvOTMLMTCKQpQjZnmviYQAMAO7k Message-ID: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <4EB170AD.1030302@riw.us> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 13:02:44 -0000 >Er, on non-transitive items like LocalPref, there is a use case for signing >them iff the iBGP elements are decided as being in-scope. >(I agree with Danny on this being worth considering.) The design team discussions had dwelt with this issue some. The thinking at the time is captured in: http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-00#section-2.4 You may also like to glace at the section where iBGP and confeds are discussed: http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-00#section-7.3 >So, when I say "signed", what I was thinking of was something along >the lines of a sequence of blocks that might look something like: >LocalBGPPerHopData >signature(LocalBGPPerHopData|previousSignature) >and after all those blocks, >originatorSignature(FirstHopData|RPKI-validatable-data) > >The stack gives a history of transitive and non-transitive values, >some of which won't be used for local policy decisions per se, and some of which >can quite reasonably have been changes at each hop. The signatures protect >that data. As I see it, there are three questions to ask here: 1. How much utility or relevance does the content of LocalBGPPerHopData have two or three hops way? 2. What exactly are the security needs of the content of LocalBGPPerHopData, and can they be met adequately with hop-by-hop transport layer protection? 3. It appears that ISPs are currently NOT used to having local info (such as LocalBGPPerHopData) carried across the Internet to ASs that are more than a hop away. So would they like all this (which may well give away business policy info) being carried in eBGP updates across the net? As an example, in the origin or path validation context, AS-A may pass on its BGP update validation results to AS-B (both ASs managed by the same ISP) in eBGP encoded in a Community attribute but does not want it to be propagated beyond AS-B. If AS-A is required to sign over that attribute (along with the NLRI or previous AS's sig), then AS-B is not in a position to supress the attribute. May be it makes sense to discuss the possibility of a separate signature for LocalBGPPerHopData that is applicable only over a single hop and then it must be dropped. That is, if relying on transport layer protection for protecting LocalBGPPerHopData is considered inadequate. Sriram From eosterweil@verisign.com Fri Nov 4 07:24:46 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF2121F8B8E for ; Fri, 4 Nov 2011 07:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIbfq5KqRICG for ; Fri, 4 Nov 2011 07:24:45 -0700 (PDT) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id A20F921F8AD8 for ; Fri, 4 Nov 2011 07:24:19 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP; Fri, 04 Nov 2011 07:24:45 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id pA4EOFh6020489; Fri, 4 Nov 2011 10:24:15 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.131.30.68]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 10:24:14 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Fri, 4 Nov 2011 10:24:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 04 Nov 2011 14:24:14.0741 (UTC) FILETIME=[6DDB8C50:01CC9AFD] Cc: "draft-ietf-sidr-algorithm-agility@tools.ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 14:24:46 -0000 Hey Steve, On Nov 4, 2011, at 4:45 AM, Stephen Kent wrote: > Eric, >=20 > 1- Yes, there is a need for global coordination for alg transition, = under the design presented. If you have an alternative proposal, please = share it. This design was originally documented in June, 2010, in an = individual I-D authored by me. It has been briefed at several SIDR WG = meetings, starting at IETF 78 in July, 2010. This is not new. I can appreciate that this document represents some long standing = thought and effort. However, the fact that I believe there is a flaw = does not seem to need the support of an alternate design, right? I'm = pointing out an operational misalignment in _this_ design. I think to = offer an alternative at the same time as we are discussing a shortcoming = here would be an inappropriate conflation (i.e. I think that would = confuse this issue with another). So, more specifically: I think that trying to mandate global = coordination at this scale is an operational non-starter. Why can't the = design be made to accommodate different choices of algorithms and = different operational schedules? I think this is actually a = requirement: that operational entities be able to choose their own = schedules and make their own configuration choices. >=20 > 2- Not exactly. The milestones, as well as the alg suite spec, will = appear in a revised version of draft-ietf-sidr-rpki-algs. Any = operational problem that requires a delay in any transition phase would = be brought to the attention of the IESG (if the SIDR WG is no longer = active) requesting that a this RFC be re-issued, with new milestone = values for the affected phase(s). I'm sorry, but I really think this is likely to have trouble in a real = operational setting. I don't think anyone would claim that the IETF's = processes operate at the same pace as operations. For instance, if = there is an emergency at the last minute of this roll, can the working = group be expected to mint a new RFC and disseminate in short order (say, = days)? There is a vey fundamental misalignment here: creating standards = and managing operations are very loosely coupled. I think this is a = very inappropriate place to try to enforce operational schedules. Eric= From eosterweil@verisign.com Fri Nov 4 08:57:11 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F232721F8B8F for ; Fri, 4 Nov 2011 08:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dzBvFXfnUXr for ; Fri, 4 Nov 2011 08:57:10 -0700 (PDT) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3E121F8B49 for ; Fri, 4 Nov 2011 08:57:10 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP; Fri, 04 Nov 2011 08:57:10 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id pA4Fv3AR000371; Fri, 4 Nov 2011 11:57:03 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.131.30.68]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 11:57:02 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Fri, 4 Nov 2011 11:57:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com> References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 04 Nov 2011 15:57:02.0562 (UTC) FILETIME=[64899C20:01CC9B0A] Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 15:57:11 -0000 On Nov 3, 2011, at 11:59 AM, Stephen Kent wrote: > At 9:32 PM -0400 11/2/11, Danny McPherson wrote: >> On Nov 2, 2011, at 11:04 AM, Stephen Kent wrote: >=20 >> More specifically, if I have perform a cost/benefit analysis it's not = at all clear to me >> that tightening exposure windows to the frequency (hours/days) you're = suggesting >> is worth the investment and fundamental shift from the stateful BGP = model we know >> today, particularly given the drive-by and targeted nature we see in = all other aspects >> of security today (e.g., APT, phishing, etc..). >=20 > I presume that your statement "fundamental shift from the stateful BGP = model..." refers to beaconing. Beaconing does create a new basis for = propagating a route, but an AS could cause the same impact on the = routing system by changing other route parameters at the same frequency, = consistent with the BGP spec. I'd prefer a better solution, but I don't = have one to offer at this time. ooc, in regards to the above: is there any detailed analysis of how much = extra overhead we can expect from these beacons if BGPSec were deployed = universally today? Specifically, the comment above, "an AS could cause = the same impact on the routing system by changing other route parameters = at the same frequency" seems to miss the point I think I see in the = objection: what if _every_ AS must do this all the time (not just a = rogue, or select few). How much extra overhead would ensue if (say) = someone took the current set of all ASes and prefixes and simulated the = extra update traffic needed in (say) a day? Maybe if we saw some = numbers that told us how many additional updates and how much additional = bandwidth this approach would require in a routing system like today's = we could understand another aspect of much of a shift we are talking = about? Eric= From eosterweil@verisign.com Fri Nov 4 12:05:27 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447B21F0C61 for ; Fri, 4 Nov 2011 12:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4P091lEksd9n for ; Fri, 4 Nov 2011 12:05:26 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id 49A411F0C49 for ; Fri, 4 Nov 2011 12:05:26 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP; Fri, 04 Nov 2011 12:05:26 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id pA4J5EQ7030403; Fri, 4 Nov 2011 15:05:14 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.131.30.68]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 15:05:14 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Fri, 4 Nov 2011 15:05:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> To: Randy Bush X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 04 Nov 2011 19:05:14.0060 (UTC) FILETIME=[AECB78C0:01CC9B24] Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 19:05:27 -0000 Hey Randy, On Nov 4, 2011, at 4:11 AM, Randy Bush wrote: >> 5) I totally agree that route leaks don't violate BGP as a protocol >> and are related to policies. But it doesn't mean route leaks are not >> security threats. Receiving spam/viruses via email is a threat >> although it doesn't violate any SMTP standards. >>=20 >> 6) route leaking is related to a BGP threat model and isn't specific >> to BGPSEC, and BGPSEC doesn't provide any protection from that = threat. >> So I'd like to second the idea of clarifying that in the document. >=20 > could someone post a clear technical explanation of WHAT a route leak > is, HOW one would definitively detect all cases of them, and WHAT one > would do about it? This is a list of three questions. Until there is discussion of the = first, it is premature to address the second two. Therefore, how about = we just choose a specific case of the first: how would BGPSec protect = against an instance of an event found here: http://puck.nether.net/bgp/leakinfo.cgi > you are correct, BGPsec tries to secure the BGP protocol against = abuse, > not protect the internet. the latter is a very worthy goal but a bit > nebulous. of course an internet draft or two might clarify that. This seems like a very pedantic distinction. Having an AS' traffic = routed through an invalid path seems like a BGP protocol abuse to me. = So, in that language, it seems to me that this issue is in scope (i.e. = if the path is to be protected, then subverting it is an abuse). Eric= From brian.peter.dickson@gmail.com Fri Nov 4 13:52:02 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AADB11E8082 for ; Fri, 4 Nov 2011 13:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.566 X-Spam-Level: X-Spam-Status: No, score=-4.566 tagged_above=-999 required=5 tests=[AWL=1.033, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RAMeMKB+M6S for ; Fri, 4 Nov 2011 13:52:01 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 78F5F21F8A6F for ; Fri, 4 Nov 2011 13:52:01 -0700 (PDT) Received: by faas12 with SMTP id s12so3646198faa.31 for ; Fri, 04 Nov 2011 13:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ajcjNjdDhe7bTdHLm3MKEQApURLvNztjAFGk4c8Pv7Q=; b=CvR/m2p0dYrixR2qBk6i1PBSokVKEnBwvKO/I4hIYwcYbh5/AO93mv2Zjp17YZZmhi eCfkjrS8R+mKQNhCN3JbDbjtoJpmKKYYghVim6jxfheWv8KtfKk9Bt0N7YNGDU9ronww Fmr/J6ZAFFNUpP6aylkm9jsyT5bf5JyzouQqA= MIME-Version: 1.0 Received: by 10.223.16.82 with SMTP id n18mr26653294faa.2.1320439920481; Fri, 04 Nov 2011 13:52:00 -0700 (PDT) Received: by 10.223.54.15 with HTTP; Fri, 4 Nov 2011 13:52:00 -0700 (PDT) In-Reply-To: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> Date: Fri, 4 Nov 2011 16:52:00 -0400 Message-ID: From: Brian Dickson To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 20:52:02 -0000 On Fri, Nov 4, 2011 at 4:11 AM, Randy Bush wrote: > could someone post a clear technical explanation of WHAT a route leak > is, I'll bite. It requires carefully a constructed definition, first: "Customer" - A is a customer of B iff A has an arrangement with B which explicitly allows B to announce A's routes to any third party, and for B to announce B's entire routing table to A. Customer is a technical arrangement, regardless of how or why that arrangement was arrived at, e.g. paying money. If A is a customer of B, A is allowed to announce A's own routes (and by extension A's customer's routes) to B. A _may_ (or may not, at A's discretion) signal to B that A wishes B to forward all (or a subset) of A's (and A's customers) routes to third parties. A is not _required_ to do so, and A may further signal that B should only send those prefixes to a subset of third parties with whom B peers. (Observe: B may always announce A's routes to B's other customers.) A route leak occurs, when B announces non-customer routes to non-customers. (Those would be routes for which B has not been given explicit _blanket_ permission to announce to third parties.) If A (a customer of B) signals to B to not announce a subset of routes to B's non-customers, but B does so anyways, that would _not_ constitute a true route-leak as such. (It would, however, be a contractual and technical issue that would normally be resolved between A and B.) If it helps, I've tried to illustrate the leak/no-leak distinction below... Brian Examples - in the following, I'll use "->" or "<-" to indicate customer relationships, and "-" to indicate non-customer (peer) relationships. The route traverses the AS's left-to-right. A is the originating ASN, and the highest letter is the receiving ASN. The following are non-route-leak paths from announcer to receiver: A - B (A peers with B) A -> B (A is a customer of B) A <- B (B is a customer of A) A -> B <- C A <- B <- C A -> B -> C A -> B -> C - D A -> B - C <- D A - B <- C <- D A -> B -> C - D <- E <- F (and so on) (There can be only one "-", and all the arrows must point towards the "-" in the ASCII stick diagram.) Any of these would be route leaks: A - B - C A <- B -> C A - B -> C A <- B - C A -> B - C -> D A <- B <- C -> D -> E (This is one of the most common sources of route-leaks. It is one of the easiest mistakes for a network engineer to do.) A -> B -> C - D <- E <- F -> G -> H (This is how the previous example usually is seen in the wild) A -> B -> C - D <- E - F <- G (Here E is accidentally providing transit to F) The special case of mutual customers (mutual transit) would be represented as: A <-> B Mutual transit/customer arrangements can legitimately do the following: A -> B <-> C -> D A <- B <-> C <- D A - B <-> C <- D A -> B <-> C - D Basically, on any given prefix announcement, "<->" can be treated as either "<-" or "->" in order to fit the "allowed" rules. If neither of those substitutions fits an existing "allowed" rule, then the result would be a route leak. Examples of mutual-transit leaks: A - B <-> C - D A <- B <-> C -> D A - B <-> C -> D From christopher.morrow@gmail.com Fri Nov 4 14:07:08 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385AC21F8AF3 for ; Fri, 4 Nov 2011 14:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.528 X-Spam-Level: X-Spam-Status: No, score=-103.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Imn3Oo87wWE for ; Fri, 4 Nov 2011 14:07:06 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2431821F8AE6 for ; Fri, 4 Nov 2011 14:07:06 -0700 (PDT) Received: by iaeo4 with SMTP id o4so3892192iae.31 for ; Fri, 04 Nov 2011 14:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mLjIgtGrKkVgmEeFc6u5dNefz/XzBPUoaVM3o/Pvnbc=; b=YfQs/LfSB0SRJLr36IFW108/7/W8Q0kRZufEF6rovdAvDwKc5oH5WcwRKKD5Uxwtpa eScsiM2H29cIqb0NBzkyEBMOX5uJbgn2GIUHmZ9uk9fShGChQdETLGpn7ZSUSqcCAhjF EVvCo5AbV7GKUbilry5g21muv1wLv6clWSBLo= MIME-Version: 1.0 Received: by 10.231.68.20 with SMTP id t20mr4290529ibi.18.1320440825770; Fri, 04 Nov 2011 14:07:05 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Fri, 4 Nov 2011 14:07:05 -0700 (PDT) In-Reply-To: <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> Date: Fri, 4 Nov 2011 17:07:05 -0400 X-Google-Sender-Auth: Pa-tpK9GvzG8HrzSlAivIxWmp9s Message-ID: From: Christopher Morrow To: Eric Osterweil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 21:07:08 -0000 On Fri, Nov 4, 2011 at 3:05 PM, Eric Osterweil wr= ote: > > This is a list of three questions. =A0Until there is discussion of the fi= rst, it is premature to address the second two. =A0Therefore, how about we = just choose a specific case of the first: how would BGPSec protect against = an instance of an event found here: > =A0 =A0 =A0 =A0http://puck.nether.net/bgp/leakinfo.cgi > I'm not randy, but I was talking about this very thing in the office today with a co-worker... I'm not clear on how anything can stop an instance like: src time prefix puck 2011-11-04 16:15:49.157742 8.10.160.0/23=09 path 2914 2828 12989 12189 3356 19181 19181 19181 Contact score blame_asn 2828 3 12989 As I read this, 12989 (highwind) is 'accidentally' announcing reachability for 8.10.160.0/23 (CWIE? AS19181). Looking at one popular source of routing data: it actually seems that the 2 people may be peers :( the route that we see is merely an artifact of their connectivity and 'poor route selection' inside their networks :( Point being that in cases like this (or really all route leak cases) the only thing that stops this is filtering routes between bgp peers. (transits, customers, SFP peers) There isn't anything in the protocol itself (which is Stephen's, Russ's, Randy's comment through out) that tells you/me/them that 12989 should not be permitted to announce this route. (looking at available data, it seems that they SHOULD, perhaps not with this ASPath, but...) How would you go about telling, from the data on the wire in bgp, that a route is a hijack? How would you propose changing the data on the wire in bgp today to do this tomorrow? Would having data you could mechanically verify about the routes and origins and relationships (say connectivity only?) between bgp peers help solve this problem? In my view I don't see a change to the BGP wire format helping, I do see existence of data to mechanically verify ownership (and perhaps connectivity information?) helping. -chris From christopher.morrow@gmail.com Fri Nov 4 14:08:36 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979DB11E8082 for ; Fri, 4 Nov 2011 14:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.534 X-Spam-Level: X-Spam-Status: No, score=-103.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqAUgma73O2o for ; Fri, 4 Nov 2011 14:08:36 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2A11D21F8AF7 for ; Fri, 4 Nov 2011 14:08:36 -0700 (PDT) Received: by iaeo4 with SMTP id o4so3893589iae.31 for ; Fri, 04 Nov 2011 14:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WqBlaKABpdJ+lbWU6dvF1rMVJ2wLdE0YD+Z6vPy31No=; b=H8C4U1VlMLwUWEeKA2bKgcjr76tj1qffIqrKliAQh/7QrBsoG6TMproQlJwJ82DhLt 8OVEr5aSIPrVPnjVRAUtrfnAGXWngvTK2ccBPPqfbUJgd25NqDY93we+MZGJG6NKG2UG QuFRRExOANG/N8Wi+DTgfMgU+uHAsKrxlFo54= MIME-Version: 1.0 Received: by 10.231.41.4 with SMTP id m4mr4205199ibe.44.1320440915834; Fri, 04 Nov 2011 14:08:35 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Fri, 4 Nov 2011 14:08:35 -0700 (PDT) In-Reply-To: <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> Date: Fri, 4 Nov 2011 17:08:35 -0400 X-Google-Sender-Auth: uzgXNX7OvzBxhgXhaoD8zrhTB8U Message-ID: From: Christopher Morrow To: Eric Osterweil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 21:08:36 -0000 On Fri, Nov 4, 2011 at 3:05 PM, Eric Osterweil wr= ote: >> you are correct, BGPsec tries to secure the BGP protocol against abuse, >> not protect the internet. =A0the latter is a very worthy goal but a bit >> nebulous. =A0of course an internet draft or two might clarify that. > > This seems like a very pedantic distinction. =A0Having an AS' traffic rou= ted through an invalid path seems like a BGP protocol abuse to me. =A0So, i= n that language, it seems to me that this issue is in scope (i.e. if the pa= th is to be protected, then subverting it is an abuse). > oops, also, still not randy, but... there are lots of ways to bend traffic in the wrong direction and still keep bgp data 'the same'. I'm not sure fixing traffic paths is doable in BGP. Do you see a way to do this in BGP? -chris From jakob.heitz@ericsson.com Fri Nov 4 14:14:40 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA42121F8B2D for ; Fri, 4 Nov 2011 14:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.789 X-Spam-Level: X-Spam-Status: No, score=-5.789 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXgfxxR8NL+0 for ; Fri, 4 Nov 2011 14:14:39 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF4521F8B29 for ; Fri, 4 Nov 2011 14:14:39 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pA4LEZvJ022124; Fri, 4 Nov 2011 16:14:37 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.52]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 4 Nov 2011 17:14:33 -0400 From: Jakob Heitz To: Brian Dickson , Randy Bush Date: Fri, 4 Nov 2011 17:14:31 -0400 Thread-Topic: [sidr] BGPSEC Threat Model ID Thread-Index: AcybM6WDtmhFpr13ScewHatJNIjEfgAAnH5Q Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A447FC046@EUSAACMS0701.eamcs.ericsson.se> References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 21:14:41 -0000 On Friday, November 04, 2011 1:52 PM, Brian Dickson <> wrote: > Examples - in the following, I'll use "->" or "<-" to indicate > customer relationships, and "-" to indicate non-customer (peer) > relationships. >=20 > Any of these would be route leaks: > A - B - C Why is this a leak? > A <- B -> C To me, this (and anything that contains it) is the only leak. --=20 Jakob Heitz.= From christopher.morrow@gmail.com Fri Nov 4 14:24:00 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C4111E8097 for ; Fri, 4 Nov 2011 14:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.54 X-Spam-Level: X-Spam-Status: No, score=-103.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwnfux6AxdeC for ; Fri, 4 Nov 2011 14:24:00 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3D711E808B for ; Fri, 4 Nov 2011 14:23:59 -0700 (PDT) Received: by qadc10 with SMTP id c10so3246466qad.31 for ; Fri, 04 Nov 2011 14:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=uxUtBQR7cf8INM8/Jh9189bdE05sxT5jFxhg0maRCmQ=; b=whLAyjx+g0B7lbh0ocAaBG6aPFDhWC1ubBJRfwZcX0SQQvs2kB+6kQwaSrJvLULYgh boUpQq0o3yU0cPcR3iXdwMKyHvdKkYc+Q6pL2LdlnrsvqXj3De6Mran0fe6BjCQSf8hj vk7f1h0wgRIzJXjMdG0Cf8rtRgw1NoGcGJk1w= MIME-Version: 1.0 Received: by 10.50.36.161 with SMTP id r1mr14565873igj.37.1320441838320; Fri, 04 Nov 2011 14:23:58 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Fri, 4 Nov 2011 14:23:58 -0700 (PDT) In-Reply-To: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> Date: Fri, 4 Nov 2011 17:23:58 -0400 X-Google-Sender-Auth: IS_4teFqOD8LTvCjA3FmoJjZez0 Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 21:24:00 -0000 On Fri, Nov 4, 2011 at 4:52 PM, Brian Dickson wrote: > On Fri, Nov 4, 2011 at 4:11 AM, Randy Bush wrote: >> could someone post a clear technical explanation of WHAT a route leak >> is, > > I'll bite. > > It requires carefully a constructed definition, first: > "Customer" - A is a customer of B iff A has an arrangement with B > which explicitly allows B to announce A's routes to any third party, > and for B to announce B's entire routing table to A. > > Customer is a technical arrangement, regardless of how or why that > arrangement was arrived at, e.g. paying money. channeling russ: "where is this arrangement publicly documented?" (So I can know it and put it into my algorithm) > If A is a customer of B, A is allowed to announce A's own routes (and > by extension A's customer's routes) to B. > A _may_ (or may not, at A's discretion) signal to B that A wishes B to > forward all (or a subset) of A's (and A's customers) routes to third > parties. > A is not _required_ to do so, and A may further signal that B should > only send those prefixes to a subset of third parties with whom B > peers. > > (Observe: B may always announce A's routes to B's other customers.) > > A route leak occurs, when B announces non-customer routes to non-customers. > > (Those would be routes for which B has not been given explicit > _blanket_ permission to announce to third parties.) > Where is this documented? (this permissions giving) How is this enforced? (the permission) what about cases of partial transit? (I sent a route to B, and requested he NOT send it to the world at large) how is that sort of thing documented? (again, channeling russ) > If A (a customer of B) signals to B to not announce a subset of routes > to B's non-customers, but B does so anyways, that would _not_ > constitute a true route-leak as such. depends on your perspective I suppose, no? Doesn't RPSL today have the ability to signal: "Send partial routes to Foo and Full routes to Bar" ? > (It would, however, be a contractual and technical issue that would > normally be resolved between A and B.) > > If it helps, I've tried to illustrate the leak/no-leak distinction below... it didn't really... re-explaining valley-free routing with mistakes due to agreements not-available 2 as-hops away isn't helpful. Routes leak, people should filter... not new knowledge. -chris From brian.peter.dickson@gmail.com Fri Nov 4 15:40:36 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3859521F8B58 for ; Fri, 4 Nov 2011 15:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.618 X-Spam-Level: X-Spam-Status: No, score=-3.618 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0dLiR2pzOQl for ; Fri, 4 Nov 2011 15:40:35 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id E083421F8B57 for ; Fri, 4 Nov 2011 15:40:34 -0700 (PDT) Received: by faas12 with SMTP id s12so3732688faa.31 for ; Fri, 04 Nov 2011 15:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BlsjpGb8umUU6nqyr/StegMgdg2rmUgQm3KdEM0R07A=; b=dgviDuP4vH2okpiis/ryPZPanWQQ9hmeLxvhBlR840KPWXAeW61RY/8Bu80MspPhNO +d0SGGLe0o/g+B2zt2gyMuA3dqXUfv7Eljqo0hhgYMYlJ4t53MfyU/oF/DjbeyddkLuE 6NVvs56in6GacBLd7nM31oRzN71LSw9e0HI+o= MIME-Version: 1.0 Received: by 10.223.94.143 with SMTP id z15mr23009487fam.32.1320446434002; Fri, 04 Nov 2011 15:40:34 -0700 (PDT) Received: by 10.223.54.15 with HTTP; Fri, 4 Nov 2011 15:40:33 -0700 (PDT) In-Reply-To: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> Date: Fri, 4 Nov 2011 18:40:33 -0400 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 22:40:36 -0000 On Fri, Nov 4, 2011 at 5:07 PM, Christopher Morrow wrote: > On Fri, Nov 4, 2011 at 3:05 PM, Eric Osterweil = wrote: > I'm not randy, but I was talking about this very thing in the office > today with a co-worker... I'm not clear on how anything can stop an > instance like: > src =A0 =A0 =A0time =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0prefix > puck =A0 =A02011-11-04 16:15:49.157742 =A0 =A0 =A08.10.160.0/23 > =A0 path > =A0 2914 2828 12989 12189 3356 19181 19181 19181 > =A0Contact =A0 score =A0blame_asn > =A0 2828 3 =A0 =A0 =A0 12989 > > As I read this, 12989 (highwind) is 'accidentally' announcing > reachability for 8.10.160.0/23 (CWIE? AS19181). Looking at one popular > source of routing data: > =A0 > > it actually seems that the 2 people may be peers :( the route that we > see is merely an artifact of their connectivity and 'poor route > selection' inside their networks :( I suspect that it is a case of "accidental back-up transit via a peer". (I have seen this personally, where it was "malicious" instead of "accident= al".) Generally, the problem with prefix-only filtering is it ignores the as-path= . If you build your upstream filter based on who your customers are (nominall= y) instead of based on where that route was learned, this can happen. > Point being that in cases like this (or really all route leak cases) > the only thing that stops this is filtering routes between bgp peers. > (transits, customers, SFP peers) There isn't anything in the protocol > itself (which is Stephen's, Russ's, Randy's comment through out) that > tells you/me/them that 12989 should not be permitted to announce this > route. (looking at available data, it seems that they SHOULD, perhaps > not with this ASPath, but...) It's actually tricky to do in reality. You have to build prefix filters AND as-path filters AND ensure that BOTH filters are applied to everything. And that doesn't necessarily always work either. Communities are a big help... > How would you go about telling, from the data on the wire in bgp, that > a route is a hijack? > How would you propose changing the data on the wire in bgp today to do > this tomorrow? I would propose adding a mandatory "bit" signaling "customer" or "non-custo= mer". In the BGPSEC context, the bit would need to be signed and kept AS-hop-by-h= op, added in a way that unambiguously shows exactly where in the AS-path it is applied, and where the bit requires both sides of the peering agree on it. No unilateral bit-setting. The status from the last AS-hop, however is all that is really needed. Local announcements start with the bit set. Going "upstream", the customer bit gets kept. Upstream is only allowed if the bit is set. Downstream is always allowed, and the bit is always cleared. Sending to peers is only allowed if the bit is set, and in the process the bit is cleared. (Mutual transit means the bits are kept and all routes are sent.) Once a route crosses a peer connection or goes "downhill", it can no longer go "uphill" or cross another peering link. Uphill N times, one peering link (optional), downhill M times. No exception= s. Of course, filtering or marking to restrict individual prefixes can be added to this, without violating the restrictions. (More restrictive, good. Less restrictive, very bad.) In fact, I'd add it to the negotiated capabilities (being offered/requested) so it gets configured on each "neighbor" statement: Transit-Offered; Transit-Accepted; or in the oddball case, both. Only if there is match between one side offering transit and the other accepting it, is the status set. In a left-to-right representation of an AS path, there would be four possibilities: XXX YYY (Y provides transit to X) XXX YYY (X provides transit to Y, i.e. Y is a customer of X) XXX

YYY (X and Y are peers) XXX YYY (X and Y are mutual transit buddies) An example representation of AS-path-plus-bit might look like: 2914 2828 12989 12189 3356 19181 19181 19181 In the above case, the sequence " .* " shows where the problem was. Having the protocol enforce the restrictions would have stopped the leak. > Would having data you could mechanically verify about the routes and > origins and relationships (say connectivity only?) between bgp peers > help solve this problem? Yes, and I believe the relationship info, even on the most recent AS-hop, would be sufficient. While the protocol enforcing it would fix things, ther= e is the issue of trusting the implementation/implementors, so I think there would still be a requirement to sign at each leg, and validate all signatur= es and hops. The sender signing her interpretation of the status, with the receiver authenticating and having the ability to reject if either the signature is bad, OR if the signed status of the relationship does not agree with the receiver's idea of the status, ensures local bad actors are caught right away. Non-local bad actors is wha= t further requires all signatures be built with the peering-type. Enforcing t= he restriction on the peering-type-path stops the leaks. > In my view I don't see a change to the BGP wire format helping, I do > see existence of data to mechanically verify ownership (and perhaps > connectivity information?) helping. Yep - and without requiring extrinsic information (i.e. does not require the information be in an IRR-type database, can be marked locally in the path, as long as t= he peering type is mutually negotiated at each hop.) Brian From randy@psg.com Fri Nov 4 17:59:35 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD2C21F8880 for ; Fri, 4 Nov 2011 17:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5vmvKfW6ooP for ; Fri, 4 Nov 2011 17:59:35 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 678E821F8801 for ; Fri, 4 Nov 2011 17:59:35 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RMUbc-000M8N-I3; Sat, 05 Nov 2011 00:59:32 +0000 Date: Sat, 05 Nov 2011 01:59:31 +0100 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 00:59:35 -0000 > Point being that in cases like this (or really all route leak cases) > the only thing that stops this is filtering routes between bgp peers. > (transits, customers, SFP peers) There isn't anything in the protocol > itself (which is Stephen's, Russ's, Randy's comment through out) that > tells you/me/them that 12989 should not be permitted to announce this > route. (looking at available data, it seems that they SHOULD, perhaps > not with this ASPath, but...) we can not know intent. to take it to one extreme, did the pakistani operator mean to 'leak' youtube's prefix or not? randy From randy@psg.com Fri Nov 4 18:21:43 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313A211E8094 for ; Fri, 4 Nov 2011 18:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JIovChHljpL for ; Fri, 4 Nov 2011 18:21:42 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id D4FAF11E8073 for ; Fri, 4 Nov 2011 18:21:42 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RMUx3-000MB4-Gl; Sat, 05 Nov 2011 01:21:42 +0000 Date: Sat, 05 Nov 2011 02:21:39 +0100 Message-ID: From: Randy Bush To: Brian Dickson In-Reply-To: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 01:21:43 -0000 > I suspect that it is a case of "accidental back-up transit via a > peer". (I have seen this personally, where it was "malicious" instead > of "accidental".) and i have seen it intentional and pre-agreed. life is not just simple customer, peer, upstream. randy From eosterweil@verisign.com Fri Nov 4 18:30:02 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EEE1F0C4F for ; Fri, 4 Nov 2011 18:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+CU3hShXwDN for ; Fri, 4 Nov 2011 18:30:01 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 421681F0C3F for ; Fri, 4 Nov 2011 18:30:01 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP; Fri, 04 Nov 2011 18:30:01 PDT Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id pA51TNxY009555; Fri, 4 Nov 2011 21:29:23 -0400 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.35]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 21:29:23 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Fri, 4 Nov 2011 21:29:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> To: Randy Bush X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 05 Nov 2011 01:29:23.0112 (UTC) FILETIME=[5919B280:01CC9B5A] Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 01:30:02 -0000 On Nov 4, 2011, at 8:59 PM, Randy Bush wrote: >> Point being that in cases like this (or really all route leak cases) >> the only thing that stops this is filtering routes between bgp peers. >> (transits, customers, SFP peers) There isn't anything in the protocol >> itself (which is Stephen's, Russ's, Randy's comment through out) that >> tells you/me/them that 12989 should not be permitted to announce this >> route. (looking at available data, it seems that they SHOULD, perhaps >> not with this ASPath, but...) >=20 > we can not know intent. >=20 > to take it to one extreme, did the pakistani operator mean to 'leak' > youtube's prefix or not? So, in the spirit of not forking the thread too many more times than = necessary, I'll try to speak to both of these comments here. Sorry, if = this misses some of context from the snipped text, lemme know if there = was important context I missed and I'll backup to that). I think the distinction between a leak and something more intentional s = a matter of policy. Knowing the policy associated with the adjacencies = that an AS is leaking over would allow leaked announcements to be = identified, right (or am I in the weeds on this)? If so, then one could = use policy to filter announcements that violate that. If an intentional = leak (i.e. path hijack) were launched, one could use the policy = statements that authorized the leak as evidence of intent, or at least a = hammer to hit someone over the head with. As for Pakistan, iirc that was an origin hijack. In this case, the = origin authenticity was the issue, and that problem should be solved = through resource certification. Eric= From randy@psg.com Fri Nov 4 18:34:53 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5951B11E80C1 for ; Fri, 4 Nov 2011 18:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOqAlpAenwmR for ; Fri, 4 Nov 2011 18:34:53 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 7A88911E8094 for ; Fri, 4 Nov 2011 18:34:51 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RMV9m-000MCw-Gb; Sat, 05 Nov 2011 01:34:50 +0000 Date: Sat, 05 Nov 2011 02:34:48 +0100 Message-ID: From: Randy Bush To: Eric Osterweil In-Reply-To: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 01:34:53 -0000 > I think the distinction between a leak and something more intentional > s a matter of policy. Knowing the policy associated with the > adjacencies that an AS is leaking over would allow leaked > announcements to be identified o We can not know intent, should Mary have announced the prefix to Bob o But Joe can formally validate that Mary did announce the prefix to Bob o Policy on the global Internet changes every 36ms, new customers, new peers, circuit moves, ... o We already have a protocol to distribute policy or its effects, it is called BGP o BGPsec validates that the protocol has not been violated, and is not about intent or business policy randy From christopher.morrow@gmail.com Fri Nov 4 18:51:51 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B99A11E80C4 for ; Fri, 4 Nov 2011 18:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.431 X-Spam-Level: X-Spam-Status: No, score=-103.431 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eXS8aOHaiRn for ; Fri, 4 Nov 2011 18:51:50 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B543D11E8091 for ; Fri, 4 Nov 2011 18:51:50 -0700 (PDT) Received: by gye5 with SMTP id 5so3559883gye.31 for ; Fri, 04 Nov 2011 18:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WqYdc//5KL7i/wpJjIwZD45zP0sYQ0FUBxUqosVt/mU=; b=dRxkuKLBleAidIijqc7N4ARiFapOSYC/n/zPQnBk4z0bUaH2clFNVgP8qisnOq9sLo 1vmzL98bao4EzhaaDmBdZZjPaSHl28g+kzCscU/duh6iM0EKbN9XI8dO2Qp6h/3tX4+4 Kmxkp0kah7ONFa0W0KRQJqoMZhDN/ooCs2OUI= MIME-Version: 1.0 Received: by 10.42.136.196 with SMTP id v4mr20452555ict.3.1320457910118; Fri, 04 Nov 2011 18:51:50 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Fri, 4 Nov 2011 18:51:50 -0700 (PDT) In-Reply-To: <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com> References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com> Date: Fri, 4 Nov 2011 21:51:50 -0400 X-Google-Sender-Auth: rayFL4gJme-0MAn4olmyKAXrlC0 Message-ID: From: Christopher Morrow To: Eric Osterweil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 01:51:51 -0000 On Fri, Nov 4, 2011 at 11:57 AM, Eric Osterweil w= rote: > > On Nov 3, 2011, at 11:59 AM, Stephen Kent wrote: > >> At 9:32 PM -0400 11/2/11, Danny McPherson wrote: >>> On Nov 2, 2011, at 11:04 AM, Stephen Kent wrote: >> > > > >>> More specifically, if I have perform a cost/benefit analysis it's not a= t all clear to me >>> that tightening exposure windows to the frequency (hours/days) you're s= uggesting >>> is worth the investment and fundamental shift from the stateful BGP mod= el we know >>> today, particularly given the drive-by and targeted nature we see in al= l other aspects >>> of security today (e.g., APT, phishing, etc..). >> >> I presume that your statement "fundamental shift from the stateful BGP m= odel..." refers to beaconing. Beaconing does create a new basis for propaga= ting a route, but an AS could cause the same impact on the routing system b= y changing other route parameters at the same frequency, consistent with th= e BGP spec. I'd prefer a better solution, but I don't have one to offer at = this time. > > ooc, in regards to the above: is there any detailed analysis of how much = extra overhead we can expect from these beacons if BGPSec were deployed uni= versally today? =A0Specifically, the comment above, "an AS could cause the = same impact on the routing system by changing other route parameters at the= same frequency" seems to miss the point I think I see in the objection: wh= at if _every_ AS must do this all the time (not just a rogue, or select few= ). =A0How much extra overhead would ensue if (say) someone took the current= set of all ASes and prefixes and simulated the extra update traffic needed= in (say) a day? =A0Maybe if we saw some numbers that told us how many addi= tional updates and how much additional bandwidth this approach would requir= e in a routing system like today's we could understand another aspect of mu= ch of a shift we are talking about? > my recollection is we ran some of these numbers (based, I think, on routeviews dump/mrt data), perhaps randy or stephen has this sort of number available? From christopher.morrow@gmail.com Fri Nov 4 18:52:46 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523B811E80A2 for ; Fri, 4 Nov 2011 18:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.54 X-Spam-Level: X-Spam-Status: No, score=-103.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoJMnOcWu0qT for ; Fri, 4 Nov 2011 18:52:45 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CE8DC11E8091 for ; Fri, 4 Nov 2011 18:52:45 -0700 (PDT) Received: by iaeo4 with SMTP id o4so4159477iae.31 for ; Fri, 04 Nov 2011 18:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JLWOHsaEmUfINt1WH4BIsjVKT9+gxfQLSert+7MY6wM=; b=D65++VopDu5y0zJXi0QsUfq9CkYLzLHovmnlkoKhhoFbjfWR986T20Gu9jotBMHpf/ qGgn6WASaIf6yYnr8CTfYFbnhYwZ2uS7Ai/juQzXXGnUKlgeYbyV9mS4X8TTZVXQbDbz 6i0qpDhMW21TaicQUmGXJ3a+j5iQAafFKatKQ= MIME-Version: 1.0 Received: by 10.231.41.4 with SMTP id m4mr4660022ibe.44.1320457965507; Fri, 04 Nov 2011 18:52:45 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Fri, 4 Nov 2011 18:52:45 -0700 (PDT) In-Reply-To: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> Date: Fri, 4 Nov 2011 21:52:45 -0400 X-Google-Sender-Auth: XpsJvDbDr3falsJw4da7vclMDtY Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 01:52:46 -0000 On Fri, Nov 4, 2011 at 8:59 PM, Randy Bush wrote: >> Point being that in cases like this (or really all route leak cases) >> the only thing that stops this is filtering routes between bgp peers. >> (transits, customers, SFP peers) There isn't anything in the protocol >> itself (which is Stephen's, Russ's, Randy's comment through out) that >> tells you/me/them that 12989 should not be permitted to announce this >> route. (looking at available data, it seems that they SHOULD, perhaps >> not with this ASPath, but...) > > we can not know intent. > > to take it to one extreme, did the pakistani operator mean to 'leak' > youtube's prefix or not? > right, the only save there is the filtering PCCW was not doing... which was my point (I believe) > randy > From christopher.morrow@gmail.com Fri Nov 4 18:57:46 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036DB21F8AF7 for ; Fri, 4 Nov 2011 18:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.544 X-Spam-Level: X-Spam-Status: No, score=-103.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2NkP4UjmBk1 for ; Fri, 4 Nov 2011 18:57:45 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE8921F8AD9 for ; Fri, 4 Nov 2011 18:57:45 -0700 (PDT) Received: by iaeo4 with SMTP id o4so4164008iae.31 for ; Fri, 04 Nov 2011 18:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/CFpPc4wTAcaqKc80EzIAkt3crIfjKuon6P4lfhLSzM=; b=asPfGFdlzb2tk1yUbB5nE+5mEpO4D6Nb59N0VFguwY88XE+h5grI1WxBGAMUb2Fw1M 6xyNUBAm029fr2mNFQPMcr/y2ILQCRLwKUMTMOn8b+hGhuVY3+IaXI8vJaIP0HXbR5Yb x2grQSWtZD5xgfNt8SxS+NBbFZZ46jVt2JLxI= MIME-Version: 1.0 Received: by 10.231.48.142 with SMTP id r14mr4768461ibf.5.1320458265176; Fri, 04 Nov 2011 18:57:45 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Fri, 4 Nov 2011 18:57:44 -0700 (PDT) In-Reply-To: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> Date: Fri, 4 Nov 2011 21:57:44 -0400 X-Google-Sender-Auth: nq6KK8mZq5q23hOSNQcIwj5hkDc Message-ID: From: Christopher Morrow To: Eric Osterweil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 01:57:46 -0000 On Fri, Nov 4, 2011 at 9:29 PM, Eric Osterweil wr= ote: > As for Pakistan, iirc that was an origin hijack. =A0In this case, the ori= gin authenticity was the issue, and that problem should be solved through r= esource certification. > or by simply applying a filter to your customer, in no world would it have been proper to accept that set of routes from PKT to PCCW. From danny@tcb.net Fri Nov 4 19:31:12 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F851F0C65 for ; Fri, 4 Nov 2011 19:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-sC4-BnT83S for ; Fri, 4 Nov 2011 19:31:12 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id E5C9C1F0C58 for ; Fri, 4 Nov 2011 19:31:11 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 296E6268063; Fri, 4 Nov 2011 20:31:00 -0600 (MDT) Received: from dul1dmcphers-m1.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Fri, 04 Nov 2011 20:30:59 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=62605; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 From: Danny McPherson Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-7-703143558 Date: Fri, 4 Nov 2011 22:30:43 -0400 In-Reply-To: To: sidr wg list References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> Message-Id: X-Mailer: Apple Mail (2.1084) Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 02:31:12 -0000 --Apple-Mail-7-703143558 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Nov 4, 2011, at 9:34 PM, Randy Bush wrote: > o We can not know intent, should Mary have announced the prefix to Bob > > o But Joe can formally validate that Mary did announce the prefix to Bob > > o Policy on the global Internet changes every 36ms, new customers, new > peers, circuit moves, ... > > o We already have a protocol to distribute policy or its effects, it is > called BGP > > o BGPsec validates that the protocol has not been violated, and is not > about intent or business policy o And therefore, BGPsec does not mitigate the leak problem, agreed o Not mitigating the leak problem could be an unacceptable residual risk to many looking to better secure BGP, particularly given that it's a natural evolution to attackers in a world of "BGPSEC/SBGP", and can happen as a simple matter of misconfiguration, as Jared's leak page illustrates: http://puck.nether.net/bgp/leakinfo.cgi o BGPSEC is awfully heavy to not address this fundamental "business policy" vulnerability o As for "bits on the wire" solutions, I don't recall seeing that as a hard requirement, although I will admit that BGPSEC certainly goes a long way to turn RPKI into "bits on the wire", which has _many implications o I'm pretty sure I can configure static routes every 36ms with far less overhead o By your definition, I'd prefer to solve the "business policy" problem. -danny --Apple-Mail-7-703143558 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

o We can not = know intent, should Mary have announced the prefix to Bob

o But = Joe can formally validate that Mary did announce the prefix to = Bob

o Policy on the global Internet changes every 36ms, new = customers, new
 peers, circuit moves, ...

o We already = have a protocol to distribute policy or its effects, it = is
 called BGP 

o BGPsec validates = that the protocol has not been violated, and is not
 about = intent or business policy

o And = therefore, BGPsec does not mitigate the leak problem, = agreed

o Not mitigating the leak problem could = be an unacceptable residual
risk to many looking to = better secure BGP, particularly given that it's = a 
natural evolution to attackers in a world of = "BGPSEC/SBGP", and can 
happen as a simple matter of = misconfiguration, as Jared's leak page

o BGPSEC is awfully heavy to = not address this fundamental "business 
policy" = vulnerability

o As for "bits on the wire" = solutions, I don't recall seeing that as a = hard 
requirement, although I will admit that BGPSEC = certainly goes a long 
way to turn RPKI into "bits = on the wire", which has _many implications

o = I'm pretty sure I can configure static routes every 36ms with far = less 
overhead

o By your = definition, I'd prefer to solve the "business policy" = problem.

-danny
= --Apple-Mail-7-703143558-- From shane@castlepoint.net Fri Nov 4 19:40:15 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5377211E8087 for ; Fri, 4 Nov 2011 19:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySNwbOesYR7U for ; Fri, 4 Nov 2011 19:40:14 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE2A11E80AA for ; Fri, 4 Nov 2011 19:40:14 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 2E8DA268063; Fri, 4 Nov 2011 20:40:14 -0600 (MDT) Received: from mbpw.castlepoint.net (65-102-206-76.hlrn.qwest.net [65.102.206.76]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Fri, 04 Nov 2011 20:40:14 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.102.206.76; client-port=55402; syn-fingerprint=65535:54:1:64:M1452,N,W2,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Shane Amante In-Reply-To: Date: Fri, 4 Nov 2011 20:39:57 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1251.1) Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 02:40:15 -0000 Hi Chris, On Nov 4, 2011, at 3:07 PM, Christopher Morrow wrote: > On Fri, Nov 4, 2011 at 3:05 PM, Eric Osterweil = wrote: >>=20 >> This is a list of three questions. Until there is discussion of the = first, it is premature to address the second two. Therefore, how about = we just choose a specific case of the first: how would BGPSec protect = against an instance of an event found here: >> http://puck.nether.net/bgp/leakinfo.cgi >>=20 >=20 > I'm not randy, but I was talking about this very thing in the office > today with a co-worker... I'm not clear on how anything can stop an > instance like: > src time prefix > puck 2011-11-04 16:15:49.157742 8.10.160.0/23=09 > path > 2914 2828 12989 12189 3356 19181 19181 19181 > Contact score blame_asn > 2828 3 12989 >=20 > As I read this, 12989 (highwind) is 'accidentally' announcing > reachability for 8.10.160.0/23 (CWIE? AS19181). Looking at one popular > source of routing data: > The specific route leak noted above would _NOT_ appear if one or more of = those AS'es was following what I thought was a "Best Current = Practice"[1] of performing AS_PATH filtering for peer ASN's showing up = on routes from their customers. Please note that this is an extremely = simple set of 3 lines of config to 'sanity check' inbound routes from = customers, (similar to and probably in the same = route-map/policy-statement that is, hopefully, rejecting RFC1918 = prefixes from customers, as well). If we can't seem to get the basics right, then how well do we expect a = much more complicated set of machinery, which doesn't currently account = for this particular scenario anyway, to perform? Or, to be more = sanguine :-), if these BCP's were used, then how much would that reduce = the attack surface area, in the _real_ world, that is presently trying = to be solved for? -shane [1] I wish I could point to an authoritative reference, but I don't = recall one. Perhaps someone with a better memory and/or search skills = can find one. > it actually seems that the 2 people may be peers :( the route that we > see is merely an artifact of their connectivity and 'poor route > selection' inside their networks :( >=20 > Point being that in cases like this (or really all route leak cases) > the only thing that stops this is filtering routes between bgp peers. > (transits, customers, SFP peers) There isn't anything in the protocol > itself (which is Stephen's, Russ's, Randy's comment through out) that > tells you/me/them that 12989 should not be permitted to announce this > route. (looking at available data, it seems that they SHOULD, perhaps > not with this ASPath, but...) >=20 > How would you go about telling, from the data on the wire in bgp, that > a route is a hijack? > How would you propose changing the data on the wire in bgp today to do > this tomorrow? >=20 > Would having data you could mechanically verify about the routes and > origins and relationships (say connectivity only?) between bgp peers > help solve this problem? >=20 > In my view I don't see a change to the BGP wire format helping, I do > see existence of data to mechanically verify ownership (and perhaps > connectivity information?) helping. >=20 > -chris > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Fri Nov 4 19:56:19 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A7211E80DD for ; Fri, 4 Nov 2011 19:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.247 X-Spam-Level: X-Spam-Status: No, score=-103.247 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbDlpd0UzGLV for ; Fri, 4 Nov 2011 19:56:18 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 948A411E80D6 for ; Fri, 4 Nov 2011 19:56:18 -0700 (PDT) Received: by ggnv1 with SMTP id v1so3602598ggn.31 for ; Fri, 04 Nov 2011 19:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FHfHbIFE88ifaBfvhpjgvA0j6gfkkRI1YunltsJ6Q8E=; b=weqbBBlXWfs1+mNGBd6f62Hik2Q5be9XL7D/aEzPM71FvC78yLHC3CDU8NkzCTVBPG B0kyGAbxly+FhDeJDgHa5mJoeVRIHcoS6LrLT2axaR4a4jvxYo5bB/pzqiL/QDzyzRrX EGlkiqVsg1nEe+Cm1NgT7uJv2NsnVJIzQZHYE= MIME-Version: 1.0 Received: by 10.50.36.161 with SMTP id r1mr16916707igj.37.1320461776263; Fri, 04 Nov 2011 19:56:16 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Fri, 4 Nov 2011 19:56:16 -0700 (PDT) In-Reply-To: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> Date: Fri, 4 Nov 2011 22:56:16 -0400 X-Google-Sender-Auth: Am7M8Eio9VTND8X4koY1yBl063o Message-ID: From: Christopher Morrow To: Shane Amante Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 02:56:19 -0000 On Fri, Nov 4, 2011 at 10:39 PM, Shane Amante wrote= : > Hi Chris, chello! > On Nov 4, 2011, at 3:07 PM, Christopher Morrow wrote: >> On Fri, Nov 4, 2011 at 3:05 PM, Eric Osterweil = wrote: >>> >>> This is a list of three questions. =A0Until there is discussion of the = first, it is premature to address the second two. =A0Therefore, how about w= e just choose a specific case of the first: how would BGPSec protect agains= t an instance of an event found here: >>> =A0 =A0 =A0 =A0http://puck.nether.net/bgp/leakinfo.cgi >>> >> >> I'm not randy, but I was talking about this very thing in the office >> today with a co-worker... I'm not clear on how anything can stop an >> instance like: >> src =A0 =A0 =A0time =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0prefix >> puck =A02011-11-04 16:15:49.157742 =A0 =A0 =A08.10.160.0/23 >> =A0 path >> =A0 2914 2828 12989 12189 3356 19181 19181 19181 >> =A0Contact =A0 score =A0blame_asn >> =A0 2828 =A0 =A0 =A0 =A03 =A0 =A0 =A0 12989 >> >> As I read this, 12989 (highwind) is 'accidentally' announcing >> reachability for 8.10.160.0/23 (CWIE? AS19181). Looking at one popular >> source of routing data: >> =A0 > > The specific route leak noted above would _NOT_ appear if one or more of = those AS'es was following what I thought was a "Best Current Practice"[1] o= f performing AS_PATH filtering for peer ASN's showing up on routes from the= ir customers. =A0Please note that this is an extremely simple set of 3 line= s of config to 'sanity check' inbound routes from customers, (similar to an= d probably in the same route-map/policy-statement that is, hopefully, rejec= ting RFC1918 prefixes from customers, as well). > agreed, some manner of prefix + as-path seems like it'd sure solve this problem. :( > If we can't seem to get the basics right, then how well do we expect a mu= ch more complicated set of machinery, which doesn't currently account for t= his particular scenario anyway, to perform? =A0Or, to be more sanguine :-),= if these BCP's were used, then how much would that reduce the attack surfa= ce area, in the _real_ world, that is presently trying to be solved for? > I agree with some of this sentiment... I think one of the hopes is that making this simpler over all (knowing that the path you see is correct & that the prefix-list/as-path filters can be made automagically) we'll get more BCP deployment. [1][2] -chris [1]: ws.edu.isoc.org/data/2006/2134808751448228e3c2055/bgpbcp.ppt [2]: csrc.nist.gov/publications/nistpubs/800-54/SP800-54.pdf > -shane > > [1] I wish I could point to an authoritative reference, but I don't recal= l one. =A0Perhaps someone with a better memory and/or search skills can fin= d one. > > >> it actually seems that the 2 people may be peers :( the route that we >> see is merely an artifact of their connectivity and 'poor route >> selection' inside their networks :( >> >> Point being that in cases like this (or really all route leak cases) >> the only thing that stops this is filtering routes between bgp peers. >> (transits, customers, SFP peers) There isn't anything in the protocol >> itself (which is Stephen's, Russ's, Randy's comment through out) that >> tells you/me/them that 12989 should not be permitted to announce this >> route. (looking at available data, it seems that they SHOULD, perhaps >> not with this ASPath, but...) >> >> How would you go about telling, from the data on the wire in bgp, that >> a route is a hijack? >> How would you propose changing the data on the wire in bgp today to do >> this tomorrow? >> >> Would having data you could mechanically verify about the routes and >> origins and relationships (say connectivity only?) between bgp peers >> help solve this problem? >> >> In my view I don't see a change to the BGP wire format helping, I do >> see existence of data to mechanically verify ownership (and perhaps >> connectivity information?) helping. >> >> -chris >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > From shane@castlepoint.net Fri Nov 4 20:12:46 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EDF21F8A96 for ; Fri, 4 Nov 2011 20:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+2glGgpFmNJ for ; Fri, 4 Nov 2011 20:12:45 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 6000721F8A7B for ; Fri, 4 Nov 2011 20:12:45 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id E238A268063; Fri, 4 Nov 2011 21:12:44 -0600 (MDT) Received: from mbpw.castlepoint.net (65-102-206-76.hlrn.qwest.net [65.102.206.76]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Fri, 04 Nov 2011 21:12:44 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.102.206.76; client-port=55509; syn-fingerprint=65535:54:1:64:M1452,N,W2,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Shane Amante In-Reply-To: Date: Fri, 4 Nov 2011 21:12:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <70A18355-789E-4FF2-8789-1AFB00CD9B8F@castlepoint.net> References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1251.1) Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 03:12:46 -0000 Hi Chris, On Nov 4, 2011, at 8:56 PM, Christopher Morrow wrote: >> The specific route leak noted above would _NOT_ appear if one or more = of those AS'es was following what I thought was a "Best Current = Practice"[1] of performing AS_PATH filtering for peer ASN's showing up = on routes from their customers. Please note that this is an extremely = simple set of 3 lines of config to 'sanity check' inbound routes from = customers, (similar to and probably in the same = route-map/policy-statement that is, hopefully, rejecting RFC1918 = prefixes from customers, as well). >=20 > agreed, some manner of prefix + as-path seems like it'd sure solve > this problem. :( Please note that, for the specific case above, I did not mention = "complicated" & "burdensome" prefix-list filtering =85 just AS_PATH = sanity check filtering, i.e.: if you see AS (FOO|BAR|BAZ) in the path, = drop (don't learn) the route. Also, I would note that this type of = configuration re-emphasizes what Russ White has said, specifically that = (this) policy is local to each AS and is _not_ 'shared' with any other = ASN. >> If we can't seem to get the basics right, then how well do we expect = a much more complicated set of machinery, which doesn't currently = account for this particular scenario anyway, to perform? Or, to be more = sanguine :-), if these BCP's were used, then how much would that reduce = the attack surface area, in the _real_ world, that is presently trying = to be solved for? >=20 > I agree with some of this sentiment... I think one of the hopes is > that making this simpler over all (knowing that the path you see is > correct & that the prefix-list/as-path filters can be made > automagically) we'll get more BCP deployment. [1][2] Thanks for the pointers =85 now I need to go read them. :-p -shane > -chris >=20 > [1]: ws.edu.isoc.org/data/2006/2134808751448228e3c2055/bgpbcp.ppt > [2]: csrc.nist.gov/publications/nistpubs/800-54/SP800-54.pdf From christopher.morrow@gmail.com Fri Nov 4 20:22:56 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3678111E80AA for ; Fri, 4 Nov 2011 20:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.533 X-Spam-Level: X-Spam-Status: No, score=-103.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igr0i9wUVZ1v for ; Fri, 4 Nov 2011 20:22:55 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B05DC11E8087 for ; Fri, 4 Nov 2011 20:22:55 -0700 (PDT) Received: by ywt2 with SMTP id 2so3623364ywt.31 for ; Fri, 04 Nov 2011 20:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1LsUfLOJWT5vDBfk+S+a+fsqbtgnhk+c666yCQbRwRM=; b=cAdz5ekjaLqu+xFfrrlSuYkGC3QoohYy7gXc58vA+lVuXxbB0L3zK5x3u8dhJFw0nl 2nInp8NojCpO6vbyA+jTVDk50v5sGEQtgDnuAUHD0Sk3jXTHuhEw//FPiOlfHWkoOmnt Pi88T2c3y815i8zBbxtf9sGOrdv4EUeLxmnGw= MIME-Version: 1.0 Received: by 10.50.36.161 with SMTP id r1mr17098889igj.37.1320463375197; Fri, 04 Nov 2011 20:22:55 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Fri, 4 Nov 2011 20:22:54 -0700 (PDT) In-Reply-To: <70A18355-789E-4FF2-8789-1AFB00CD9B8F@castlepoint.net> References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> <70A18355-789E-4FF2-8789-1AFB00CD9B8F@castlepoint.net> Date: Fri, 4 Nov 2011 23:22:54 -0400 X-Google-Sender-Auth: lCVly6NQ26_zOKXLuH8qNsuCl4I Message-ID: From: Christopher Morrow To: Shane Amante Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 03:22:56 -0000 On Fri, Nov 4, 2011 at 11:12 PM, Shane Amante wrote= : >> >> agreed, some manner of prefix + as-path seems like it'd sure solve >> this problem. :( > > Please note that, for the specific case above, I did not mention "complic= ated" & "burdensome" prefix-list filtering =85 just AS_PATH sanity check fi= ltering, i.e.: if you see AS (FOO|BAR|BAZ) in the path, drop (don't learn) = the route. =A0Also, I would note that this type of configuration re-emphasi= zes what Russ White has said, specifically that (this) policy is local to e= ach AS and is _not_ 'shared' with any other ASN. understood, don't disagree... and yes, Russ's point about the local policy not being exposed publicly means ... we can't today figure this out easily. -chris From gih@apnic.net Fri Nov 4 21:10:36 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF3421F84A5 for ; Fri, 4 Nov 2011 21:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.429 X-Spam-Level: X-Spam-Status: No, score=-100.429 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-1RNIuwYMnu for ; Fri, 4 Nov 2011 21:10:02 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 778B621F8493 for ; Fri, 4 Nov 2011 21:09:54 -0700 (PDT) Received: from [192.168.50.152] (unknown [213.164.30.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 94DA9B6761 for ; Sat, 5 Nov 2011 14:09:52 +1000 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Geoff Huston In-Reply-To: Date: Sat, 5 Nov 2011 15:09:47 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <10A3F6FD-1392-4E6E-A048-A8EED1E8C329@apnic.net> References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> To: sidr wg list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 04:10:36 -0000 On 05/11/2011, at 12:34 PM, Randy Bush wrote: >> I think the distinction between a leak and something more intentional >> s a matter of policy. Knowing the policy associated with the >> adjacencies that an AS is leaking over would allow leaked >> announcements to be identified >=20 > o We can not know intent, should Mary have announced the prefix to Bob I disagree with this assertion of impossibility. The intention of the = routing policy databases in their various flavours and incarnations was to = publish intent and allow others to filter based on intent. Yes, there is a viable form of filtering wayward prefix advertisements that are of the form of adherence or otherwise to published intent, and = if everybody scrupulously entered the entirety of their routing policy into some form of routing policy database then indeed there could be a viable case to be made that you could create a routing security framework based on such foundations. So I'm not dismissive about the impossibility to know intent. One can in theory know intent, and filter based on intent. In many ways this is not so much different than what is going on with = the effort to secure the outcome operation of the protocol. In this case the = routing intent of the originator is not exposed, but it is possible to expose = the relationship between the originator and the prefix holder, and expose the = authenticity of inter-AS transactions that are described in the AS path. Again the same = observation is that this only really works if everyone plays along, otherwise the = gaps in the knowledge based of signed attestations cripple the general = benefit of the outcome. So these are two different sides of a validation coin, if you'll pardon = the analogy. One side says "I have no idea if BGP is being warped and = twisted or not, but if what I hear from my peer conforms to the set of published = routing policies, then I'll accept the update", while the other says "I have no idea if this was intentional or not, but what I have received is not the result of warping and twisting the operation of the BGP in unnatural = ways then I'll accept the update". I suspect that most of this thread is these two points of view arguing = past=20 each other. From jakob.heitz@ericsson.com Fri Nov 4 21:21:13 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341151F0C54 for ; Fri, 4 Nov 2011 21:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.905 X-Spam-Level: X-Spam-Status: No, score=-5.905 tagged_above=-999 required=5 tests=[AWL=0.694, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kXxiu3F5Rpy for ; Fri, 4 Nov 2011 21:21:12 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id A96E11F0C50 for ; Fri, 4 Nov 2011 21:21:12 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pA54L8Nm026418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Nov 2011 23:21:08 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.52]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sat, 5 Nov 2011 00:21:07 -0400 From: Jakob Heitz To: Brian Dickson Date: Sat, 5 Nov 2011 00:21:34 -0400 Thread-Topic: [sidr] BGPSEC Threat Model ID Thread-Index: Acybcla262Fvr1qCTvu67V+GjIFqrw== Message-ID: <110BD765-3943-4442-846B-F73C8B632E3B@ericsson.com> References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 04:21:13 -0000 On Nov 4, 2011, at 3:41 PM, "Brian Dickson" = wrote: > Once a route crosses a peer connection or goes "downhill", it can no > longer go "uphill" > or cross another peering link. Why can it not cross a peering link? -- Jakob Heitz.= From brian.peter.dickson@gmail.com Fri Nov 4 21:35:14 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7732621F86A1 for ; Fri, 4 Nov 2011 21:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.617 X-Spam-Level: X-Spam-Status: No, score=-3.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLUiX7yy6YB3 for ; Fri, 4 Nov 2011 21:35:14 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9C21E21F86A0 for ; Fri, 4 Nov 2011 21:35:13 -0700 (PDT) Received: by faas12 with SMTP id s12so3908205faa.31 for ; Fri, 04 Nov 2011 21:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Al6Yvf+q0f2rPE7T0c+vGqEBkuB3kQTCwq7YkFBzidk=; b=cBeag9W/NS7loxVVQcTD09eLtKGHD1nNAoMgV1BSj8Ii3kR1FJVO5SUeabTYNOwwy3 RpH4x3rwmpiFGA5ME708R10/kL3+OnIljQZQ2aKorK7O2anP1PMoCWDJOIu6iAzSEU/c iZoOpVyNI695JA3ANuonJEofS6ZlqmoJDnY2s= MIME-Version: 1.0 Received: by 10.223.6.129 with SMTP id 1mr18521240faz.17.1320467712686; Fri, 04 Nov 2011 21:35:12 -0700 (PDT) Received: by 10.223.54.15 with HTTP; Fri, 4 Nov 2011 21:35:12 -0700 (PDT) In-Reply-To: <110BD765-3943-4442-846B-F73C8B632E3B@ericsson.com> References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> <110BD765-3943-4442-846B-F73C8B632E3B@ericsson.com> Date: Sat, 5 Nov 2011 00:35:12 -0400 Message-ID: From: Brian Dickson To: Jakob Heitz Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 04:35:14 -0000 On Sat, Nov 5, 2011 at 12:21 AM, Jakob Heitz wrote: > On Nov 4, 2011, at 3:41 PM, "Brian Dickson" wrote: > >> Once a route crosses a peer connection or goes "downhill", it can no >> longer go "uphill" >> or cross another peering link. > > Why can it not cross a peering link? > > -- > Jakob Heitz. When two networks peer, they agree to exchange routes for their respective customers. If A announces a route to B, that route is A's customer and _not_ B's customer. So, by the nature of the agreements, B cannot announce that route to another peer, C. Take the worst case - a tier-1 network. All their routes are either customer routes, or peer routes. If they were to send their peers' routes to their peers, they would be sending all routes to everyone. They would be providing transit, for free, to their peers. This would not be good for many reasons. Put another way - when network B sends routes to peer C, it is providing transit to those routes. It generally only wants to do that for customers, especially if that happens to be its primary business. Brian From russw@riw.us Sat Nov 5 05:34:08 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D62921F8922 for ; Sat, 5 Nov 2011 05:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBKp2VntcxzL for ; Sat, 5 Nov 2011 05:34:08 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id D67CF21F847C for ; Sat, 5 Nov 2011 05:34:07 -0700 (PDT) Received: from rtp-isp-nat1.cisco.com ([64.102.254.33]:10166 helo=[10.117.153.102]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RMfRk-0001pE-OJ; Sat, 05 Nov 2011 08:34:04 -0400 Message-ID: <4EB52D41.1040203@riw.us> Date: Sat, 05 Nov 2011 08:34:09 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christopher Morrow References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <4EB170AD.1030302@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: sidr@ietf.org Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 12:34:08 -0000 > Did you really mean to sign the next-hop? it seems infeasible... The constant answer to any challenges to the requirements documents is: "We are simply protecting BGP semantics with signatures." 1. Signing a semantic doesn't make it secure. 2. If you're going to claim you're all about protecting BGP semantics, then protect all of them, not just one. > Also, LocalPref is a locally used/determined/created (non-transitive) > item, adding that set of bits into the signature seems blatantly > wrong, since the data won't exist when you pass the route outside your > ASN the verification is going to fail, for every route you send (which > had a localpref != default), That CERTAINLY seems like something you > would want to avoid, right? So what you are saying is that you don't want to protect attributes that aren't carried more than one hop through the internetwork --I.e., next hop is only carried between one set of (presumably) locally connected eBGP peers, so it shouldn't be protected. This leaves us with two problems. == 1. Since many other attributes carried in this fashion actually impact the usability or trustworthiness of a route, what justification can you give for not protecting them? Because it's "too hard?" 2. You say: AS1--AS2--AS3 AS1 shouldn't care about what goes on between AS2 and AS3. But wait... Then why should AS1 care about the AS Path interactions between AS2 and AS3, precisely? How can AS1 really trust that traffic it sends to AS2 will actually be forwarded through AS3 if next-hop games are going on between AS2 and AS3? Or local pref games are going on within AS2? Or AS3 is sending AS2 some community that AS2 is locally interpreting in some way that would impact AS1's decision about forwarding along that path? The reality is that local decisions impact the global reliability of each piece of routing information. == I would posit all this confusion comes from simply not doing a good job of defining the problem in the first place. A solution was chosen first, and then a problem set found that this specific solution could "solve" (and no other!), regardless of the secondary problems and complexity the chosen solution might happen to bring to the table. Which is why I oppose adoption of this draft as a WG document. :-) Russ From russw@riw.us Sat Nov 5 05:48:49 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1605B21F8663 for ; Sat, 5 Nov 2011 05:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzciDEc-am9W for ; Sat, 5 Nov 2011 05:48:48 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAD621F8610 for ; Sat, 5 Nov 2011 05:48:48 -0700 (PDT) Received: from rtp-isp-nat1.cisco.com ([64.102.254.33]:47106 helo=[10.117.153.102]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RMffz-0008Bq-Iu for sidr@ietf.org; Sat, 05 Nov 2011 08:48:47 -0400 Message-ID: <4EB530B4.4090803@riw.us> Date: Sat, 05 Nov 2011 08:48:52 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sidr@ietf.org References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> <10A3F6FD-1392-4E6E-A048-A8EED1E8C329@apnic.net> In-Reply-To: <10A3F6FD-1392-4E6E-A048-A8EED1E8C329@apnic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 12:48:49 -0000 >> o We can not know intent, should Mary have announced the prefix to Bob Let me point out a fundamental issue here. Security is, and always has been, about matching intent with reality. If I lock my doors, there is an implied intent that no-one go into my house (in band). If I give a neighbor a key, I will give them explicit instructions as to my intent --"only go in if the dog is barking, or to feed the dog, or..." (out of band) You MUST know intent to provide security. Get over it. You can't match expectations to reality unless you know what the expectations are. What is the entire security model of the RPKI and origin auth? To ensure the intent of the RIR in assigning address space is followed, and to ensure the intent of the owner of that address space is carried out. You could argue that you're only trying to secure the "semantics of BGP," which means you're trying to enforce the intent of the BGP specifications (you can't get away from intent!), but that opens up another wormhole of problems. "You can't prove intent" is a red herring. :-) Russ From russw@riw.us Sat Nov 5 06:00:13 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30EF21F86F6 for ; Sat, 5 Nov 2011 06:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrOlpExp32g1 for ; Sat, 5 Nov 2011 06:00:13 -0700 (PDT) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 59EE721F84BA for ; Sat, 5 Nov 2011 06:00:13 -0700 (PDT) Received: from rtp-isp-nat1.cisco.com ([64.102.254.33]:14635 helo=[10.117.153.102]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RMfr2-0003Y3-BW for sidr@ietf.org; Sat, 05 Nov 2011 09:00:12 -0400 Message-ID: <4EB53360.1080109@riw.us> Date: Sat, 05 Nov 2011 09:00:16 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sidr@ietf.org References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> <70A18355-789E-4FF2-8789-1AFB00CD9B8F@castlepoint.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 13:00:14 -0000 >> Please note that, for the specific case above, I did not mention "complicated"& "burdensome" prefix-list filtering … just AS_PATH sanity check filtering, i.e.: if you see AS (FOO|BAR|BAZ) in the path, drop (don't learn) the route. Also, I would note that this type of configuration re-emphasizes what Russ White has said, specifically that (this) policy is local to each AS and is _not_ 'shared' with any other ASN. > > understood, don't disagree... and yes, Russ's point about the local > policy not being exposed publicly means ... we can't today figure this > out easily. Unless you're willing to expose your policy publicly, or at least within the realm of partners you expect to help you enforce it. One of the problems with SIDR has been the constant insistence that "policy not be exposed publicly." I'll say it again. 1. All security is about exposing and enforcing intent. 2. You can only secure intent you know and understand. You can't expect someone who doesn't know what you mean to do what you want, no matter how nicely you ask. 3a. We can decide that those who want to secure anything must publicly (or semi-publicly) declare what it is they want secured. 3b. We can decide that we "only want to secure the BGP spec," which opens another wormhole (though if that's the wormhole you'd like to go down, I'd be happy to transfer this work to IDR, where the experts on that spec live). 3c. We can continue down the path of, "we can't tell anyone what we want them to do, we just expect them to read our minds and do what we intended." SIDR seems determined to do 3c, no matter how unwise or how unrealistic. :-) Russ From brian.peter.dickson@gmail.com Sat Nov 5 11:34:25 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793C121F8591 for ; Sat, 5 Nov 2011 11:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.016 X-Spam-Level: X-Spam-Status: No, score=-3.016 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599, J_CHICKENPOX_101=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IfhYjSJPVEy for ; Sat, 5 Nov 2011 11:34:24 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 319A921F858D for ; Sat, 5 Nov 2011 11:34:24 -0700 (PDT) Received: by faas12 with SMTP id s12so4409823faa.31 for ; Sat, 05 Nov 2011 11:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AWmyiEUxPGIeU3F3npEWOetUmiNBQ0BriUUW+DEZwf8=; b=V1P5n7ciarwRBYPzpO387BUHScrvXTBxOgnVZUF6QQj6D+tGPpayI23W2Z3iTNnnao s0Rz/I819S2yTnidqjJfxOBwTjQkvyjXySJ/y6lINGpXMYKx8CsY+dVX48UpjNbG3oGy vcY+qU9CiA4w4GO3Sf3q4vuRt11ENoHeInRm0= MIME-Version: 1.0 Received: by 10.223.76.27 with SMTP id a27mr33461073fak.12.1320518063290; Sat, 05 Nov 2011 11:34:23 -0700 (PDT) Received: by 10.223.54.15 with HTTP; Sat, 5 Nov 2011 11:34:22 -0700 (PDT) In-Reply-To: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> Date: Sat, 5 Nov 2011 14:34:22 -0400 Message-ID: From: Brian Dickson To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 18:34:25 -0000 On Fri, Nov 4, 2011 at 9:34 PM, Randy Bush wrote: >> I think the distinction between a leak and something more intentional >> s a matter of policy. =A0Knowing the policy associated with the >> adjacencies that an AS is leaking over would allow leaked >> announcements to be identified > > o We can not know intent, should Mary have announced the prefix to Bob This is a semantic issue, and I think can best be viewed within the realm of knowing/proving. You can't prove a positive, but you can prove a negative. If the semantics regarding intent are limited to negatives, I believe it is possible to correctly infer one aspect of intent. See below for an analogy... > o Policy on the global Internet changes every 36ms, new customers, new > =A0peers, circuit moves, ... So long as the policy expression point is eBGP peering sessions, and that marking is mandatory and inherited by routes crossing those sessions, the 36ms issue itself becomes moot. BGP is stateful, and all of these things that involve the above new/changed eBGP things (peering sessions, customers, peers) involve stateful changes. Tying policy (and policy changes) to only eBGP sessions, regardless of other things that influence route announce/withdraw/attribute-change means routes marked when crossing eBGP boundaries will always be statefully-correct. (The presumption is that _policy changes_ on eBGP will automatically require re-announcement of all prefixes across that session, either by forced soft reconfig outbound enforced by the protocol, or an actual session reset.) Here is what I hope is a useful analogy to illustrate "negative intent". Consider the realm of business communications of written material, e.g. either paper or via signed (S/MIME) email. Consider this realm where the only additional policy component is the Non-Disclosure Agreement. Presume NDA material is presumed here to always be marked, including with who the NDA parties are. Also presume chain-of-custody style marking history, if material is re-sent to other parties. Presume NDAs permit material to be communicated to parent companies, to subsidiaries, and even to joint-venture subsidiaries. Presume NDAs permit material to be exchanged between the signatories, and their subsidiaries, and vice versa. Presume NDAs do not permit sharing with any other party. Presume NDAs do not permit joint-venture subsidiaries who receive material from one parent, to be sent to the other parent, even the other parent is one of the two NDA signatories. (Think of this as parents -> subsidiaries having additional/separate NDAs that also get stamped on material shared to the subsidiary.) Presume NDA material exchanged by their respective subsidiaries can only be sent directly via the signatories themselves. Now consider the scenario when someone who isn't a signatory with any of the above NDAs between A and B, i.e. someone who is neither A, nor B, nor a subsidiary or joint-venture subsidiary (direct or indirect) of A or B. The recipient has a chain-of-custody cover sheet showing who sent it to who= m. A responsible actor would do what with this document? (I propose the answer, presuming every document is a duplicate, not an original, is to destroy it.) A bad actor might use it, and might forward it to someone else. The party receiving from a bad actor is able to correctly infer from the attached NDAs and chain of custody documents, that the immediate sender is in fact a bad actor. I would argue that regardless of why or how one receives such a document, the _definition_ of bad actor can be derived from whether or not he/she destroys the improperly communicated document. A bad actor is _de_facto_ someone who accepts the document without destroying it. Note also, in this arbitrary analogy, the following also apply: - not every document has an NDA. - not every extra-org arrangement will be NDA'd - chain-of-custody is presumed to be based on crypto, and includes chaining of signatures (a la BGPsec's current I-D doc) - chain-of-custody is present whether there is an NDA or not - multiple NDAs can be present, esp. when documents are sent to subsidiary^n'th org) - NDA was chosen because it generally is included in employment agreements governing behavior of individual actors within an organization - Employment agreements may even have restrictions on improperly-received non-public (NDA) material to which employer is not an NDA signatory And finally, here's how this analogously applies to a possible addition to BGP/BGPSEC: - adding a flag or flags to eBGP peering sessions, indicating: - whether or not the sender wants to _limit_ distribution of routes that are sent (to just recipient's "customers" - should be default on, turned off only when sender is transit customer of recipient); - whether or not the sender wants to _send_ (otherwise) distribution-limited routes (e.g. those learned from peers - default off, turned on only when sender is transit provider to recipient) - whether or not the recipient will _accept_ (otherwise) distribution-limited routes (e.g. from a transit provider - default off, turned on only when recipient is trasnti customer of sender) - default values equate to "true peer" - I send my customers' routes (and customer^n'th routes), and distribute your routes only to my customers. - Controls automatic blocking only; local policy cannot override this blocking, but can do anything else it wants/need. If local policy is being blocked, there are ways to change the peering flag-bits to enable that policy (caveat emptor) - Permits implementation of any neighbor-neighbor policies, including mutual transit - Blocks route leaks in all cases except (idiotic) multi-party mutual transit (more than one consecutive hop with mutual transit), and even then, route leakage is constrained to at most one AS-hop away from such a contiguous mutual-transit "mess" - Requires only signaling negative-intent - ''Don't send this in an unconstrained fashion". It's the only (new) bit set on routes; the rest of the bits on peering session control whether/when this bit gets set, or when/how to block based on this bit. The intent is clear, even when the route is seen many AS-hops away. Some things just work better when done on a white board interactively - sorry if this is not as clear as it was intended. Brian From brian.peter.dickson@gmail.com Mon Nov 7 11:08:45 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF5211E80A3 for ; Mon, 7 Nov 2011 11:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTSSIbX4qSDr for ; Mon, 7 Nov 2011 11:08:45 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id B5ACA11E80A0 for ; Mon, 7 Nov 2011 11:08:44 -0800 (PST) Received: by faas12 with SMTP id s12so6498615faa.31 for ; Mon, 07 Nov 2011 11:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=us6ksHH/QCfM9qgeJxvXccD/JSz2TV1YNwMNpFTWIjA=; b=adDvFR3se78pme51WW+xrZJNpwalnq1Shs5+eLRNys0YYI2K85xoKocjTFXpduiLGC 8oyj5+7C2pInx9sc3yE/8mjReeH2lkSR1A1tGTJh7LqW4MODlMpWe0sk6M1JcmHYiy43 dDIFA68QWomoHDzXKfhxORPmiFwEXoi4U9yxA= MIME-Version: 1.0 Received: by 10.223.76.27 with SMTP id a27mr48778145fak.12.1320692923671; Mon, 07 Nov 2011 11:08:43 -0800 (PST) Received: by 10.223.54.15 with HTTP; Mon, 7 Nov 2011 11:08:43 -0800 (PST) In-Reply-To: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> Date: Mon, 7 Nov 2011 14:08:43 -0500 Message-ID: From: Brian Dickson To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 19:08:45 -0000 On Fri, Nov 4, 2011 at 9:21 PM, Randy Bush wrote: >> I suspect that it is a case of "accidental back-up transit via a >> peer". =A0(I have seen this personally, where it was "malicious" instead >> of "accidental".) > > and i have seen it intentional and pre-agreed. =A0life is not just simple > customer, peer, upstream. > > randy I think many of us have seen "special" arrangements, either first-hand, or involving our customer(s) as one or more of the parties to such an arrangement. I think if we categorize neighbors as "customer, transit, peer, special", that is still useful. Here's why: - as a general rule, "special" is negotiated between parties (two, or more-than-two, doesn't matter) - it is fine to have "customer" include "customer's customer et al", and even "customer's special neighbor" iff the customer wants - except when all the parties are part of a single "special" arrangements, "special" is non-transitive. - there can be many pools of "special", even with overlapping membership - pretty much by definition, "special" pools are contiguous - outside of that contiguous area, the boundary to that special area can be treated as a normal AS (by non-participants) - in fact, special pools could almost be treated like an AS Confederation The last two points basically say, if we ignore the goings-on within such a region, applying the simple rules (customer/transit/peer) are sufficient to prevent leaks crossing any boundary other than between region members. Take as a whole, this is more than sufficient benefit to employ, so long as it is possible for members of such regions to "remove the safeties". The exposure is strictly intra-region at that point, which is a lot better than it is today. Mechanisms for preventing route leaks don't have to necessarily be perfect to be useful, IMHO. Keeping the mechanics themselves simple, and the semantics clear, is the second most important part. Sensible defaults is the most important. Third is allowing network admins to disable them as needed. Kind of analogous to the three laws of robotics, now that I think about it.= .. Brian From kent@bbn.com Mon Nov 7 11:56:47 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E082821F853E for ; Mon, 7 Nov 2011 11:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.355 X-Spam-Level: X-Spam-Status: No, score=-106.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USA0OLiBzSRh for ; Mon, 7 Nov 2011 11:56:47 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 538D821F8532 for ; Mon, 7 Nov 2011 11:56:47 -0800 (PST) Received: from dhcp89-089-006.bbn.com ([128.89.89.6]:49163) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RNVIr-000KpO-Gu; Mon, 07 Nov 2011 14:56:21 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> Date: Mon, 7 Nov 2011 14:46:37 -0500 To: Eric Osterweil From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 19:56:48 -0000 >... > >I can appreciate that this document represents some long standing >thought and effort. However, the fact that I believe there is a >flaw does not seem to need the support of an alternate design, >right? I'm pointing out an operational misalignment in _this_ >design. I think to offer an alternative at the same time as we are >discussing a shortcoming here would be an inappropriate conflation >(i.e. I think that would confuse this issue with another). The authors do not agree that the global coordination requirement is a flaw. >So, more specifically: I think that trying to mandate global >coordination at this scale is an operational non-starter. Why can't >the design be made to accommodate different choices of algorithms >and different operational schedules? I think this is actually a >requirement: that operational entities be able to choose their own >schedules and make their own configuration choices. If there is not a schedule when old algs die and new ones MUST be supported, then one at least doubles the size of the repository system, and imposes a burden on all CAs and RPs to support old algs forever. > > 2- Not exactly. The milestones, as well as the alg suite spec, >will appear in a revised version of draft-ietf-sidr-rpki-algs. Any >operational problem that requires a delay in any transition phase >would be brought to the attention of the IESG (if the SIDR WG is no >longer active) requesting that a this RFC be re-issued, with new >milestone values for the affected phase(s). > >I'm sorry, but I really think this is likely to have trouble in a >real operational setting. I don't think anyone would claim that the >IETF's processes operate at the same pace as operations. For >instance, if there is an emergency at the last minute of this roll, >can the working group be expected to mint a new RFC and disseminate >in short order (say, days)? There is a vey fundamental misalignment >here: creating standards and managing operations are very loosely >coupled. I think this is a very inappropriate place to try to >enforce operational schedules. I think you overstate the problem. The intervals for each phase are not expected to be short, and there are phases that accommodate both old and new als in a fashion that allows considerable CA and RP flexibility. Nonetheless, I think Terry's suggestion has merit. I can imagine having the milestone RFC be coordinated through the NRO and IANA, and published by the IETF, to help ensure that there is appropriate ISP input to the milestone development. Steve From eosterweil@verisign.com Mon Nov 7 14:45:13 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866C71F0C3E for ; Mon, 7 Nov 2011 14:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJqdec7DN1x1 for ; Mon, 7 Nov 2011 14:45:12 -0800 (PST) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id BCD2E1F0C38 for ; Mon, 7 Nov 2011 14:44:51 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP; Mon, 07 Nov 2011 14:45:12 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id pA7MiZaZ028016; Mon, 7 Nov 2011 17:44:35 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.35]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Nov 2011 17:44:34 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Mon, 7 Nov 2011 17:44:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3F1388E3-A694-42C9-AE2F-F12BF15DC86F@verisign.com> References: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 07 Nov 2011 22:44:34.0787 (UTC) FILETIME=[D2704B30:01CC9D9E] Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 22:45:13 -0000 On Nov 7, 2011, at 2:46 PM, Stephen Kent wrote: >> ... >>=20 >> I can appreciate that this document represents some long standing = thought and effort. However, the fact that I believe there is a flaw = does not seem to need the support of an alternate design, right? I'm = pointing out an operational misalignment in _this_ design. I think to = offer an alternative at the same time as we are discussing a shortcoming = here would be an inappropriate conflation (i.e. I think that would = confuse this issue with another). >=20 > The authors do not agree that the global coordination requirement is a = flaw. >=20 >> So, more specifically: I think that trying to mandate global = coordination at this scale is an operational non-starter. Why can't the = design be made to accommodate different choices of algorithms and = different operational schedules? I think this is actually a = requirement: that operational entities be able to choose their own = schedules and make their own configuration choices. >=20 > If there is not a schedule when old algs die and new ones MUST be = supported, then one at least doubles the size of the repository system, = and imposes a burden on all CAs and RPs to support old algs forever. Sorry, but I think freedom from global coordination is more than an = inconvenient, or unpalatable, concept. It is something that (afaict) = has been an inherent requirement in those Internet-scale systems that = have survived to date. I don't think there is any precedent of an = operational system of this scale that requires this level of global = coordination of its configuration, is there? What Internet-scale system = of a scale remotely as large as BGP has this kind of global coordination = model? What is the evidence that such an approach will work here? I think this may be suggesting that more requirements analysis is needed = before we can have total faith in the design work. If this particular = design implicitly requires something that seems to be a non-starter, = then I would say that seriously undermines the design and more design = work is likely required. I have a specific example below... >=20 >>> 2- Not exactly. The milestones, as well as the alg suite spec, will = appear in a revised version of draft-ietf-sidr-rpki-algs. Any = operational problem that requires a delay in any transition phase would = be brought to the attention of the IESG (if the SIDR WG is no longer = active) requesting that a this RFC be re-issued, with new milestone = values for the affected phase(s). >>=20 >> I'm sorry, but I really think this is likely to have trouble in a = real operational setting. I don't think anyone would claim that the = IETF's processes operate at the same pace as operations. For instance, = if there is an emergency at the last minute of this roll, can the = working group be expected to mint a new RFC and disseminate in short = order (say, days)? There is a vey fundamental misalignment here: = creating standards and managing operations are very loosely coupled. I = think this is a very inappropriate place to try to enforce operational = schedules. >=20 > I think you overstate the problem. The intervals for each phase are = not expected to be short, and there are phases that accommodate both old = and new als in a fashion that allows considerable CA and RP flexibility. >=20 > Nonetheless, I think Terry's suggestion has merit. I can imagine = having the milestone RFC be coordinated through the NRO and IANA, and = published by the IETF, to help ensure that there is appropriate ISP = input to the milestone > development. Sorry, but this really misses the issue I was trying to describe. = Suppose you have a very well-planned / longterm schedule in place. As = you march towards one of these cutover dates, suppose there is any = operational problem (hardware failure, software failure, network = partitioning of part of the system, newly discovered problems with the = plan, etc). At the "last minute" at least one operational body cannot = meet the deadline. How do you even securely verify that an operator = needs to stop (as opposed to an impostor trying to halt things)? Then = what? A new RFC in the 11th hour? How is this overstating the problem? = There are two very different processes at play here: standards and = policies get hammered out in their own time, operations happen whenever = a problem feels like rearing its head. I really think that conflating = the two is a non-starter because they are governed by fundamentally = different things, and so are their schedules. Honestly, if someone = needs to call a screeching halt to a rollover, how should that happen = just days or hours before an RFC's deadline? I think this is = complicated by the fact that even if the NRO or IANA or anyone else = actually can mint an RFC in a matter of hours (is that possible?), how = would you guarantee that anyone else trying to respect the original RFC = date even knows of the change? Since global coordination is a = requirement, they all have to be in sync either way, right? I suppose = if some portion of the operators don't get the message and start the = rollover anyway, then we have another problem, yes? Eric From kent@bbn.com Mon Nov 7 15:38:43 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D197C1F0C45 for ; Mon, 7 Nov 2011 15:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.416 X-Spam-Level: X-Spam-Status: No, score=-106.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5X0c4kifkqg for ; Mon, 7 Nov 2011 15:38:43 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE651F0C44 for ; Mon, 7 Nov 2011 15:38:43 -0800 (PST) Received: from dhcp89-089-006.bbn.com ([128.89.89.6]:49176) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RNYlu-0006cB-PM; Mon, 07 Nov 2011 18:38:34 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <3F1388E3-A694-42C9-AE2F-F12BF15DC86F@verisign.com> References: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> <3F1388E3-A694-42C9-AE2F-F12BF15DC86F@verisign.com> Date: Mon, 7 Nov 2011 18:38:25 -0500 To: Eric Osterweil From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 23:38:43 -0000 Eric, I didn't miss your point; I just do not agree with it. I was noting that Terry suggested that a milestone doc ought to reflect input from the CAs and RPs, and that the NRO and IANA are reasonable candidates for such input coordination. You have said, repeatedly, that you feel that a global schedule for alg transition is a terrible idea. You have explained why you believe so. I have grave doubts about the high level scenario that you have described. Your comments seem to ignore the fact that the transition plan incorporates phases precisely to enable CAs and RPs to verify that they have working code to deal with the new alg suite before the old one is turned off. You postulate a major problem that precludes a transition to a new alg Suite (presumably for Phase 4), but that phase occurs only after CAs have been generating products and RPs have been consuming them for some time. This is not a productive discussion. Steve From terry.manderson@icann.org Mon Nov 7 18:16:04 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF21F1F0C5A for ; Mon, 7 Nov 2011 18:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.581 X-Spam-Level: X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIn09ae4QuC0 for ; Mon, 7 Nov 2011 18:16:04 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 491401F0C52 for ; Mon, 7 Nov 2011 18:16:04 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 7 Nov 2011 18:16:03 -0800 From: Terry Manderson To: Stephen Kent Date: Mon, 7 Nov 2011 18:16:01 -0800 Thread-Topic: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 Thread-Index: Acya0JOR6LlpJ1v3RTy2BU4+selLRAC68hyb Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-sidr-algorithm-agility@tools.ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 02:16:04 -0000 On 4/11/11 6:56 PM, "Stephen Kent" wrote: >=20 > I think the BCP idea is appropriate. I don't agree with your gray > area argument. Let's avoid terms like "desperate." >=20 >> But neither this document (in blessing the idea) nor >> draft-ietf-sidr-rpki-algs (as standards track) is the place for it. >=20 > let's just say we disagree, modulo the idea of putting the milestones in > a BCP. O.k Sure. Remove the date specification going into the sidr-rpki-algs document and construct whatever words are needed to say that the WG will adopt a BCP wor= k item helped along by the NRO, IANA (and it's operator), IAB etc. Modulo the WG approval and WG Chair's happiness with this direction. :-) >=20 > >=20 > In principle the RIRs & IANA, perhaps the NRO & IANA, would be an > appropriate group to issue such a statement. So far, this process has > been rocky, which is probably why there is an IAB-issused statement > re IANA as a global TA for the RPKI. Nonetheless, this might be a > reasonable split of responsibility, i.e., alg spec through the IETF > process, and milestone publication via an RFC authored by the NRO and > IANA. >=20 I think that is a step forward. I'll look for the revised draft and will read as soon as I can. Terry From brian.peter.dickson@gmail.com Mon Nov 7 22:27:44 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC14721F8CE9 for ; Mon, 7 Nov 2011 22:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.29 X-Spam-Level: X-Spam-Status: No, score=-3.29 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KHVOKx+ckyt for ; Mon, 7 Nov 2011 22:27:44 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id E223F21F8CE8 for ; Mon, 7 Nov 2011 22:27:43 -0800 (PST) Received: by faas12 with SMTP id s12so214661faa.31 for ; Mon, 07 Nov 2011 22:27:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NMrY5TMRtK3DlJYR2iZrW6bNwJpZuCEM2tf0bU3cpBU=; b=tzshjsHv/pex7UZUNuy1RwgQhT7BWLmfLbeDWUsB42TbEUSE5GooUQRurl6mZ5xvOX KuB7m/bi7IClh1+NZsVBUuGlYRiMW2GI6eEHvEykZTvrL2sKzga9xrmXu3WbAFRIPkRE kvUxRAZE0w75bgfm2JSEvROn79rpMrLL758Fw= MIME-Version: 1.0 Received: by 10.223.58.8 with SMTP id e8mr14114568fah.27.1320733661737; Mon, 07 Nov 2011 22:27:41 -0800 (PST) Received: by 10.223.54.15 with HTTP; Mon, 7 Nov 2011 22:27:41 -0800 (PST) In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6025FEE@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6025FEE@Hermes.columbia.ads.sparta.com> Date: Tue, 8 Nov 2011 01:27:41 -0500 Message-ID: From: Brian Dickson To: "Murphy, Sandra" Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 06:27:44 -0000 Sorry for the late reply. I have been following the discussion, and reviewing all the related items (normative/informative). I will note that the compartmentalized design of the ROA elements of SIDR mean it is possible to update pieces easily. However, on the mere mortal reviewer of component IDs, it puts a larger burden. It is well worth the cost, IMHO. I hope my comments aren't too late. Given the number of other items in the WG that had informally extended periods, I would appreciate leniency here. My main comment is as follows: I do not support adoption of this document in its current form. The main reasons have to do with fundamental aspects which at a high level have been addressed by my colleagues, especially with respect to timelines imposed by the IETF, or even IESG or IAB, whether directly in BCP or RFC, or indirectly via ICANN or IANA. More to the point - I am not sure if I understand the relationship between some of the elements involved, but I believe there is no strict requirement for all members of a CA hierarchy to maintain identical algorithms. Here's why: - everybody is a CA. Both the "root" of the INR tree (ICANN/IANA), plus the RIRs, etc., down to the publishers of EE certs. - each CA publishes its policy via a CPS (it's a SHOULD, but functionally a MUST for RPs to be able to understand what a CA publishes.) - Each CPS specifies the OID of the corresponding CP - Each CP refers to the corresponding policy for algorithms - Algorithms themselves have OIDs and are referenced as such in certs - Every cert also specifies the OID of the CP itself (which embodies the rules for allowed algorithms) So while the first revision of the CP insists on only one algorithm for pub/private keys, and one algorithm for hashes, it explicitly calls out that these are expected to change. In changing allowed algorithms, it can reasonably be inferred that CPs could be issued which increase the _number_ of allowed algoriths of both types beyond one. And similarly, the methodology demonstrated by key rollover has local scope. There is no requirement that children do anything at all when a parent executes a key roll. _This is by design_. So the analogous high-level design for agility SHOULD be as follows: - new CP documents may be published, with new OIDs - ONLY when a CA with a given CPS decides to change CP does that CA need to execute a locally-significant key+alg roll - The CA would issue new certs with the new CP which itself lists additional algorithms - The same procedure would be executed in multiple phases - issue new child certs published under the old main cert; move them to the new cert, rewriting/overwriting in the same location This could be handled gracefully by having two CPs - one CP having the additional algorithm(s), and subsequently another CP with the new but minus the old. This mechanism could be used to introduce new algorithms without requiring retiring specific old algorithms. The two actions - adding and removing - are in fact independent, beyond the requirement that there be at least one algorithm (which goes without saying, really). The only other requirement is that the issued certs have algorithms consistent with the specified CP (OID) attached to the cert. I may be completely off the mark, but this would seem to be much more in line with the whole manner in which algorithms, policies, resource objects, etc., have been separated out and linked by normative reference. Perhaps we could get Geoff Huston to comment on my interpretation of the CP/CPS/alg interaction and explicit/implicit rules? Is it intended that CAs have a uniform hierarchy using exactly one algorithm set, or is it intended that each CA be able to specify (via CPS + CP) the set of algorithms it supports, with the initial CP document being the minimum acceptable algorithm set? Modulo the interaction between parents/children, and requiring old algorithms to be retired, and having a set timeline, and having all global CAs on the same timetable, the general methodology for handling the phases seems pretty solid. IMHO. Brian From rogaglia@cisco.com Tue Nov 8 02:41:13 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF4021F8CBD for ; Tue, 8 Nov 2011 02:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.189 X-Spam-Level: X-Spam-Status: No, score=-7.189 tagged_above=-999 required=5 tests=[AWL=2.809, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6Xc7Z1vdsu4 for ; Tue, 8 Nov 2011 02:41:12 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3A20721F8CB7 for ; Tue, 8 Nov 2011 02:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=16562; q=dns/txt; s=iport; t=1320748871; x=1321958471; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=f/CybbLUeDTuZeLOt/MzvltzMrL4aI3zRSVDiLzjBkI=; b=b7E+2Pc2qTJsXI81jwW6kWGy35/J7Mbzd8Tfn+hUyZ8uNmT9xZ+FP6pD Dvgf7yhfI+CSu6y+6RZfjd/vrGktCHZCbIIbwMyif9iLdVxIjJcf0Pmbd ZiLHmPbf1vsxNcSk+FlKVR26wFeoD0jj9NRXs10qYzR4bredt8oiYIDiS E=; X-Files: smime.p7s : 4389 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQFAB0HuU6Q/khL/2dsb2JhbABDoiEBhjyBJYEFgXIBAQEDAQEBAQ8BWwsFCwtGAiUwBhMih2AImGwBnx+ISmMElCGRbw X-IronPort-AV: E=Sophos;i="4.69,476,1315180800"; d="p7s'?scan'208,217";a="121060253" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2011 10:41:02 +0000 Received: from dhcp-vlan250-10-147-19-222.cisco.com (dhcp-vlan250-10-147-19-222.cisco.com [10.147.19.222]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA8Af21Q022017; Tue, 8 Nov 2011 10:41:02 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-122-991758355; protocol="application/pkcs7-signature"; micalg=sha1 From: Roque Gagliano In-Reply-To: Date: Tue, 8 Nov 2011 11:40:54 +0100 Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F6025FEE@Hermes.columbia.ads.sparta.com> To: Brian Dickson X-Mailer: Apple Mail (2.1084) Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 10:41:13 -0000 --Apple-Mail-122-991758355 Content-Type: multipart/alternative; boundary=Apple-Mail-121-991754300 --Apple-Mail-121-991754300 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Brian,=20 Thanks for your comments. Please see inline. Roque (snif) >=20 > So the analogous high-level design for agility SHOULD be as follows: > - new CP documents may be published, with new OIDs The CP document in section 6.1.5 refers the definition of the Algorithm = Suite to the draft-ietf-sidr-rpki-algs document. There are not OID = defined in the CP document. That is why in our document we refer to an = update of this document instead. > - ONLY when a CA with a given CPS decides to change CP does that CA > need to execute a locally-significant key+alg roll > - The CA would issue new certs with the new CP which itself lists > additional algorithms > - The same procedure would be executed in multiple phases - issue new > child certs published under the old main cert; move them to the new > cert, rewriting/overwriting in the same location >=20 In section 4.1 we defined:=20 CA Ready Algorithm B Date - After this date, all (non-leaf) CAs MUST be ready to process a request from a child CA to issue a certificate under the Algorithm B suite If I summarize your comment, you are stating that the definition of = "ready" for a CA should also include an update on its CPS to refer to = the new suite. This was understood but as what each CA will need to do = to be ready to process requests from a child CA is local to that CA, we = did not got into the details.=20 The process that you have described is indeed the proposed algorithm in = the document for the CAs, where we adopted a "top-down" process and we = maintain the two suites independent. The document also includes the = transition to the new suite on the RPs that are distributed globally.=20 Regards, Roque > This could be handled gracefully by having two CPs - one CP having the > additional algorithm(s), and subsequently another CP with the new but > minus the old. >=20 > This mechanism could be used to introduce new algorithms without > requiring retiring specific old algorithms. The two actions - adding > and removing - are in fact independent, beyond the requirement that > there be at least one algorithm (which goes without saying, really). > The only other requirement is that the issued certs have algorithms > consistent with the specified CP (OID) attached to the cert. >=20 > I may be completely off the mark, but this would seem to be much more > in line with the whole manner in which algorithms, policies, resource > objects, etc., have been separated out and linked by normative > reference. > Perhaps we could get Geoff Huston to comment on my interpretation of > the CP/CPS/alg interaction and explicit/implicit rules? > Is it intended that CAs have a uniform hierarchy using exactly one > algorithm set, or is it intended that each CA be able to specify (via > CPS + CP) the set of algorithms it supports, with the initial CP > document being the minimum acceptable algorithm set? >=20 > Modulo the interaction between parents/children, and requiring old > algorithms to be retired, and having a set timeline, and having all > global CAs on the same timetable, the general methodology for handling > the phases seems pretty solid. >=20 > IMHO. >=20 > Brian > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-121-991754300 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Brian, 

Thanks for your = comments.
Please see = inline.

Roque



So the analogous high-level design for agility = SHOULD be as follows:
- new CP documents may be published, with new = OIDs


The CP = document in section 6.1.5 refers the definition of the Algorithm Suite = to the draft= -ietf-sidr-rpki-algs<= /a> document. There are not OID defined in the CP document. That is why = in our document we refer to an update of this document = instead.

- ONLY when a CA = with a given CPS decides to change CP does that CA
need to execute a = locally-significant key+alg roll
- The CA would issue new certs with = the new CP which itself lists
additional algorithms
- The same = procedure would be executed in multiple phases - issue new
child = certs published under the old main cert; move them to the new
cert, = rewriting/overwriting in the same = location


In section 4.1 we = defined: 
   CA Ready Algorithm B Date  =
- After this date, all (non-leaf) CAs MUST
               be ready to process a request from a child CA to issue a
               certificate under the Algorithm B =
suite
If I summarize your comment, you are stating that = the definition of "ready" for a CA should also include an update on its = CPS to refer to the new suite. This was understood but as what each CA = will need to do to be ready to process requests from a child CA is local = to that CA, we did not got into the = details. 

The process that you have = described is indeed the proposed algorithm in the document for the CAs, = where we adopted a "top-down" process and we maintain the two suites = independent. The document also includes the transition to the new suite = on the RPs that are distributed = globally. 

Regards,
Roque



= --Apple-Mail-121-991754300-- --Apple-Mail-122-991758355 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEFyqcUyRFrhvN5s0SHw/EO4wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA1MTAwMDAwMDBaFw0x MjA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxIp28SUiJ/fiFYD/Nct8MUbG WJuPqSnhkfBYMFbbWfDDrHR8OXzK2LkWIuHY5aeAo1nalAQCO40oeTYt0cp9W++a7USNCEDQzgVN Rg0YMYL27YSQoVJnecO3u9wi0jjwhJGblWWxphaztdaMbqiChgND1PHqf7dcs4UjeUOhhKFk0/61 mTmduV721jrxj6ABIlUHAc7nXhKANtDbKdBZzEhM4dbzp6STKq65EQ3xRLVFIuapTgNVckvXtc1e Cyu4xLOLZgaD2aLq9JzBn9y/rFRMtf2euP/Nmzl7QRjAUjpPdo1n6NXWGDtNyR0lUrcJ/x1leccZ Gfj0eaqe+tpJmQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAsvqKrlga/tU0vyBtnBOj 4miDAZxou0/fN2wVEK7dRLzIQLYEJD35sELVhiP8v8wVHtgOeVHz9FyBEVqXmJ0RKy4kMC7gdQxj +t1MlqSTDShEaPMmiwaK6M1iJ9jpBL4JvoiirpHnQYGukkgvTUeqITWZ5ecg03nB3QHuab91Gc+n RZ1OKL4D4p5IkvzWhRlIAlxW9yGZyB8r9V6iu3+1SYEpPPUN3AYCxXeXrn8fJjkOoEodybRiGyfW pMpShpTZg2tHB7ZX162Ti3sRvwA2mktDMnBtEm1pXo15z7yieDUPmjVybMA4byV7AQcbIrjQj0eq c/biBsueC2KWoJY7TDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRIfD8Q7jAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEx MDgxMDQwNThaMCMGCSqGSIb3DQEJBDEWBBRYNkLaJKQBUl3oqdS9nTcLjxyi/DCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQCpaTlhtC8R1Pqh7pWWLqDRbHz9PpyHQOP9XIhAmvKbbu4S o/1dImymbZsWRgw24YFlCt59C+q5x3eJ26qJhNIbxO9vtwEdwN55jIY2koDhm60q2/uY0Wl3gaB3 HdW/am6l56ZA0H8ajFrdXe4e+A0ubTzH1gl+QUILsw3Oja3q7122s1CSUi8ajm0aRfOJXDbMLifG ZsxTdqAGvG8KKMRh9DgK8JhdFs6rSZ6VTpaJS9k3yYqsLH7ig5t1DGFzlFExL1+NYRdSEp3Qr9B8 mBA884sMYpcpAGfnTrSCU+1mmXydQmHfvV622ZR7zp43C1YSARgNcG0DKKkpVN4JGjZ2AAAAAAAA --Apple-Mail-122-991758355-- From brian.peter.dickson@gmail.com Tue Nov 8 04:48:22 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6999721F8B29 for ; Tue, 8 Nov 2011 04:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.278 X-Spam-Level: X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g51nVYOFqMKG for ; Tue, 8 Nov 2011 04:48:21 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id E662521F8B39 for ; Tue, 8 Nov 2011 04:48:18 -0800 (PST) Received: by faas12 with SMTP id s12so579190faa.31 for ; Tue, 08 Nov 2011 04:48:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vcqSfABbNjB2HFkhnCKsCDcDLJPvnkOsKj8V7HrztAY=; b=lRfPH8+DaBTnQ9a/VCtC/gKjDxNX8A7jc+H39gqIgaDO8bYfJ9q2+GA935gbK52fj0 HchQNXmKKLYRNXG7Fwlk2GOrRuEIFfruAcj0pQGVPzaWCV+a0JUzDBmsgV2i7xFmqmXS fzjLpzmJiNALHdgKmkmDZyWRuMYV+TUtVdJ50= MIME-Version: 1.0 Received: by 10.223.58.8 with SMTP id e8mr16150742fah.27.1320756498025; Tue, 08 Nov 2011 04:48:18 -0800 (PST) Received: by 10.223.54.15 with HTTP; Tue, 8 Nov 2011 04:48:17 -0800 (PST) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F6025FEE@Hermes.columbia.ads.sparta.com> Date: Tue, 8 Nov 2011 07:48:17 -0500 Message-ID: From: Brian Dickson To: Roque Gagliano Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 12:48:22 -0000 On Tue, Nov 8, 2011 at 5:40 AM, Roque Gagliano wrote: > Hi Brian, > Thanks for your comments. > Please see inline. > Roque > > (snif) > > So the analogous high-level design for agility SHOULD be as follows: > - new CP documents may be published, with new OIDs > > > The CP document in section 6.1.5 refers the definition of the Algorithm > Suite to the=A0draft-ietf-sidr-rpki-algs document. There are not OID defi= ned > in the CP document. That is why in our document we refer to an update of > this document instead. I was actually referring to the OID _of_ the CP document itself, draft-ietf-sidr-cp-17, in section 1.2. And in draft-ietf-sidr-res-certs-22, section 9, use of that OID is referenced, including how the change of OID gets handled. The change-of-OID process identified there would be necessary, even if the res-certs format did not change, so long as there was some other reason for the OID change. And in draft-ietf-sidr-cp-17, section 9.12.3 describes when the OID must ch= ange. Clearly, changing the algorithm RFC used by the CP, would require a new CP = with a new OID, since it directly affects acceptability of RPKI certificates. > - ONLY when a CA with a given CPS decides to change CP does that CA > need to execute a locally-significant key+alg roll > - The CA would issue new certs with the new CP which itself lists > additional algorithms > - The same procedure would be executed in multiple phases - issue new > child certs published under the old main cert; move them to the new > cert, rewriting/overwriting in the same location > > > In section 4.1 we defined: > > CA Ready Algorithm B Date - After this date, all (non-leaf) CAs MUST > be ready to process a request from a child CA to issue a > certificate under the Algorithm B suite What I am saying is, there is no reason to require a change to a child's CP= S, and thus its CP, and thus its algorithm suite, simply because the parent CA is making this change. The whole 'all (non-leaf)' stuff is un-necessary. Each CA may operate its CPS independently. Algorithms are explicitly includ= ed via OIDs in every cert. A child CA may need to sign with algorithms accepte= d by the parent CA, but they can issue certs with a different CP, signed accordi= ng to the algorithms _of_that_CP_ (their own CP, independent of the choice of CP used by the parent CA). The choice of algorithm acceptability for a given cert, comes from the CP. It needs internal consistency. There is no further requirement on algorithm choice. > If I summarize your comment, you are stating that the definition of "read= y" > for a CA should also include an update on its CPS to refer to the new sui= te. > This was understood but as what each CA will need to do to be ready to > process requests from a child CA is local to that CA, we did not got into > the details. Okay, yes, that was the bit I said was technically correct... > The process that you have described is indeed the proposed algorithm in t= he > document for the CAs, where we adopted a "top-down" process and we mainta= in > the two suites independent. The document also includes the transition to = the > new suite on the RPs that are distributed globally. That's the part I disagree with entirely - there is no "top-down" required at all. There is no "globally". There is only the requirement operationally that any newly published CP with new OID be supported by RPs. The publishing the new CP with new OIDs with sufficient time for RPs to implement those changes is the only timeline issue. It is a "sunrise" issue - a minimum time after publication before ANY CA begins to issue certs using the new OID. After that date, any CA may choose to use the new CP, without requiring any change to either the CA's parent, or the CA's children, except as relates to the algorithms used on new certs, which the child needs to discover. This has no bearing o= n the CP _used_ by the child CA in issuing certs to grand-child CAs - that is under the local policy of the child CA. Every CA is free to choose the CP it uses from among the published CPs, mod= ulo the issue date plus delay required (6 months in the initial CP document). Issuing a second (or third, or fourth) CP does _not_require_ANY_ CA to chan= ge algorithm suite. Perhaps a separate BCP can recommend, or even require, use of some subset of CP documents, or at some point an old CP could be moved to historic or depracated status. However, that should _not_ be part of the alg-agility document. Agility should limit itself to the mechanism by which a _single_ CA changes algorithm suite, including the possibility that the new suite still include all the algorithm(s) from the previous suite, the possibility that multiple algorithms are part of the new suite, as well as case of (but not a requirement that) _an_ older algorithm is dropped from the suite. > Regards, > Roque Sincerely, Brian From kotikalapudi.sriram@nist.gov Tue Nov 8 04:59:57 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A29721F8C73 for ; Tue, 8 Nov 2011 04:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2ilDtlFM+FV for ; Tue, 8 Nov 2011 04:59:56 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 52D0421F8C70 for ; Tue, 8 Nov 2011 04:59:56 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 8 Nov 2011 07:59:51 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 8 Nov 2011 07:59:20 -0500 From: "Sriram, Kotikalapudi" To: Christopher Morrow , Eric Osterweil Date: Tue, 8 Nov 2011 07:59:19 -0500 Thread-Topic: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs Thread-Index: AcybXWurdtT3WRtaQp6LmdnTiZU3aQCtndH+ Message-ID: References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 12:59:57 -0000 > > ooc, in regards to the above: is there any detailed analysis of how much extra overhead we can expect from these beacons if BGPSec were deployed universally today? Specifically, the comment above, "an AS could cause the same impact on the routing system by changing other route parameters at the same frequency" seems to miss the point I think I see in the objection: what if _every_ AS must do this all the time (not just a rogue, or select few). How much extra overhead would ensue if (say) someone took the current set of all ASes and prefixes and simulated the extra update traffic needed in (say) a day? Maybe if we saw some numbers that told us how many additional updates and how much additional bandwidth this approach would require in a routing system like today's we could understand another aspect of much of a shift we are talking about? > Eric, According to http://bgpupdates.potaroo.net/instability/bgpupd.html the current global BGP system produces Average Prefixes per BGP Update: 2.24 Average BGP Update Messages per second: 1.13 Average Prefix Updates per second: 2.53 >From this we can compute: Average Prefix Updates per day = 218696 Now if we consider a BGPSEC island of 100,000 participating prefixes (multiple ISPs form a BGPSEC island and there is BGPSEC between them and also in each ISP's entire customer cone): With 24 hour beaconing interval, we would have: Prefix Updates per Day = 100,000 (seen at each BGPSEC router) BGPSEC Update Size = 420B (for ECDSA-256) Average Bandwidth Required = 3.89 kbps (averaged over a day) Does this answer what you were asking for? Sriram _______________________________________________ From rogaglia@cisco.com Tue Nov 8 06:17:02 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3442521F8CB4 for ; Tue, 8 Nov 2011 06:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.894 X-Spam-Level: X-Spam-Status: No, score=-8.894 tagged_above=-999 required=5 tests=[AWL=1.705, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoR8h7pBfwvw for ; Tue, 8 Nov 2011 06:17:01 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id DCBE421F899F for ; Tue, 8 Nov 2011 06:17:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=8817; q=dns/txt; s=iport; t=1320761821; x=1321971421; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=yoqS5NPjZqjf5SXwgXQ1cCvjQDdxkoyM1tJ6xPH7HM4=; b=Yf7C5elIswfCN0UpOFLLcZJJlfsOP8J5bU+jV5FeuXhgkdD86Tesl9qJ vWqAzwwYMJRvg+giZkC9FLB9/n5igG4WhbSLrfuX0m/M7mlJ9Pubp//8H MxnZ+34AZPpHV0/gxcDObgTJM4Ar9wF26b6aQ1EtjY6S1AhET15menHfW g=; X-Files: smime.p7s : 4389 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANg4uU6Q/khN/2dsb2JhbAA6CaoHgQWBcgEBAQMBEgFgBgULC0YCVQY1h2CYcQGfJYV9gk1jBJQhkW8 X-IronPort-AV: E=Sophos;i="4.69,477,1315180800"; d="p7s'?scan'208";a="59424259" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 08 Nov 2011 14:16:59 +0000 Received: from dhcp-vlan250-10-147-19-222.cisco.com (dhcp-vlan250-10-147-19-222.cisco.com [10.147.19.222]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA8EGwo1022771; Tue, 8 Nov 2011 14:16:58 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-236-1004717977; protocol="application/pkcs7-signature"; micalg=sha1 From: Roque Gagliano In-Reply-To: Date: Tue, 8 Nov 2011 15:16:55 +0100 Message-Id: <083152D5-D693-4BD4-A1D9-325C78192E8A@cisco.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6025FEE@Hermes.columbia.ads.sparta.com> To: Brian Dickson X-Mailer: Apple Mail (2.1084) Cc: "sidr@ietf.org wg" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 14:17:02 -0000 --Apple-Mail-236-1004717977 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Brian, Lets focus on this part: > That's the part I disagree with entirely - there is no "top-down" > required at all. > There is no "globally". There is only the requirement operationally > that any newly > published CP with new OID be supported by RPs. >=20 > The publishing the new CP with new OIDs with sufficient time for RPs > to implement > those changes is the only timeline issue. It is a "sunrise" issue - a > minimum time > after publication before ANY CA begins to issue certs using the new = OID. This is fine in a model where every CA lives in its own island (think on = the identity case) but not in our case. A CA needs to issue a = certificate-signing-request to its parent CA. The WG decided to not allow "mixed" CA certificates. Consequently, you = need your parent to be "ready" before been able to issue the CSR. This = is the reason for the "top-down" requirement. So for "any" CA to issue = certs using the new OID it needs that it parent has migrated first. The rest of your reasoning seams to go around the same concept. Roque. > After that date, any CA may choose to use the new CP, without > requiring any change > to either the CA's parent, or the CA's children, except as relates to > the algorithms > used on new certs, which the child needs to discover. This has no = bearing on the > CP _used_ by the child CA in issuing certs to grand-child CAs - that > is under the > local policy of the child CA. > Every CA is free to choose the CP it uses from among the published = CPs, modulo > the issue date plus delay required (6 months in the initial CP = document). >=20 > Issuing a second (or third, or fourth) CP does _not_require_ANY_ CA to = change > algorithm suite. >=20 > Perhaps a separate BCP can recommend, or even require, use of some = subset > of CP documents, or at some point an old CP could be moved to historic = or > depracated status. >=20 > However, that should _not_ be part of the alg-agility document. > Agility should limit > itself to the mechanism by which a _single_ CA changes algorithm > suite, including > the possibility that the new suite still include all the algorithm(s) > from the previous > suite, the possibility that multiple algorithms are part of the new > suite, as well as > case of (but not a requirement that) _an_ older algorithm is dropped > from the suite. >=20 >> Regards, >> Roque >=20 > Sincerely, > Brian --Apple-Mail-236-1004717977 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEFyqcUyRFrhvN5s0SHw/EO4wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA1MTAwMDAwMDBaFw0x MjA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxIp28SUiJ/fiFYD/Nct8MUbG WJuPqSnhkfBYMFbbWfDDrHR8OXzK2LkWIuHY5aeAo1nalAQCO40oeTYt0cp9W++a7USNCEDQzgVN Rg0YMYL27YSQoVJnecO3u9wi0jjwhJGblWWxphaztdaMbqiChgND1PHqf7dcs4UjeUOhhKFk0/61 mTmduV721jrxj6ABIlUHAc7nXhKANtDbKdBZzEhM4dbzp6STKq65EQ3xRLVFIuapTgNVckvXtc1e Cyu4xLOLZgaD2aLq9JzBn9y/rFRMtf2euP/Nmzl7QRjAUjpPdo1n6NXWGDtNyR0lUrcJ/x1leccZ Gfj0eaqe+tpJmQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAsvqKrlga/tU0vyBtnBOj 4miDAZxou0/fN2wVEK7dRLzIQLYEJD35sELVhiP8v8wVHtgOeVHz9FyBEVqXmJ0RKy4kMC7gdQxj +t1MlqSTDShEaPMmiwaK6M1iJ9jpBL4JvoiirpHnQYGukkgvTUeqITWZ5ecg03nB3QHuab91Gc+n RZ1OKL4D4p5IkvzWhRlIAlxW9yGZyB8r9V6iu3+1SYEpPPUN3AYCxXeXrn8fJjkOoEodybRiGyfW pMpShpTZg2tHB7ZX162Ti3sRvwA2mktDMnBtEm1pXo15z7yieDUPmjVybMA4byV7AQcbIrjQj0eq c/biBsueC2KWoJY7TDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRIfD8Q7jAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEx MDgxNDE2NThaMCMGCSqGSIb3DQEJBDEWBBQZbewrTZvtxrd9gCVn4VoDe+iadjCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQCPrfrCetzuc96KjwEepIXbc5OgSWblw0neGRd27hC7WrWt XHhyjcPJ1g3V+jFQwOngr3B1uiC7lnxkdwtudguJwuQueE+KTMbgAWbOyF/8LUfKfFnHQxqLXHs0 d1/o1Ksg0oDKA1niCzZfMo85Lspf5rU+2iU+eK2kkl+CDnlJPhvmT2GgN1ptVFeWXbjYuOKCOAxC YGD9YJ8GymIduPlbWwsxu6ShKC/ZNPQ98a1QGnRAEbqNnos1P9pZK2CUBs+ekavWKAt1fNRPTimW fcbk2RKUyKImvzru7+l+/QuPvy4vlslKnFOlvwzyCp/61nuhzr5nwhfSQtHWPdem3Hc2AAAAAAAA --Apple-Mail-236-1004717977-- From russw@riw.us Tue Nov 8 06:27:31 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F6E21F8C67 for ; Tue, 8 Nov 2011 06:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jej8j3TQGTe0 for ; Tue, 8 Nov 2011 06:27:30 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 91C4821F8AEE for ; Tue, 8 Nov 2011 06:27:30 -0800 (PST) Received: from [12.180.141.130] (port=54093 helo=[63.140.190.249]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RNme9-0007MN-3q for sidr@ietf.org; Tue, 08 Nov 2011 09:27:29 -0500 Message-ID: <4EB93C4F.1070302@riw.us> Date: Tue, 08 Nov 2011 09:27:27 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sidr@ietf.org References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com>, In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 14:27:31 -0000 > Now if we consider a BGPSEC island of 100,000 participating prefixes > (multiple ISPs form a BGPSEC island and there is BGPSEC between > them and also in each ISP's entire customer cone): > With 24 hour beaconing interval, we would have: > Prefix Updates per Day = 100,000 (seen at each BGPSEC router) It's one additional update per table entry per day, assuming a 24 hour beacon. If the table is 300,000 routes, it's 300,000 additional updates a day --on top of normal churn. The 24 hour "beacon rate," is a bad assumption anyway --once operators catch on to this being the actual amount of time you're willing to allow others to hijack your routes, the rate will shorten up considerably. There's no "downward limit" on the time, and there's no real economic incentive for the originator to choose longer times. At some point you're going to be forced to put in timers per AS Path hop --since the signature in the packet represents the policy and connectivity between every pairwise set in the AS Path, every pairwise set also needs a timer. Added together, we are talking at least a doubling of the rate at which updates are received (and probably more like a tripling or quadrupling over time), at least a quadrupling of the total traffic in terms of bits/second (assuming the lowest possible update rates)--and all of this counts the cost of actually handling the crypto inbound and outbound as zero. Russ From randy@psg.com Tue Nov 8 06:42:42 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D7021F8C67 for ; Tue, 8 Nov 2011 06:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYGWNZP-SHGi for ; Tue, 8 Nov 2011 06:42:41 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A9E1F21F8C49 for ; Tue, 8 Nov 2011 06:42:41 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RNmsq-0008Ah-GN; Tue, 08 Nov 2011 14:42:40 +0000 Date: Tue, 08 Nov 2011 15:42:39 +0100 Message-ID: From: Randy Bush To: Russ White In-Reply-To: <4EB93C4F.1070302@riw.us> References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 14:42:42 -0000 > It's one additional update per table entry per day, assuming a 24 hour > beacon. If the table is 300,000 routes, it's 300,000 additional > updates a day --on top of normal churn. note that this is not churn, in the sense of fib update, which is 90% of the cost of an update. > At some point you're going to be forced to put in timers per AS Path > hop nope. gains absolute zero replay protection. see my preso from VdeQ. but i am not really interested in the noise about beaconing. as i said in VdeQ, the feature is nice but not all that important. randy From russw@riw.us Tue Nov 8 06:57:43 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6474F21F8CD4 for ; Tue, 8 Nov 2011 06:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IE2h3nTGkbIW for ; Tue, 8 Nov 2011 06:57:43 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 0184321F8C60 for ; Tue, 8 Nov 2011 06:57:42 -0800 (PST) Received: from [12.180.141.130] (port=54383 helo=[63.140.190.249]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RNn7N-0004uY-Sw; Tue, 08 Nov 2011 09:57:41 -0500 Message-ID: <4EB94363.2090809@riw.us> Date: Tue, 08 Nov 2011 09:57:39 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Randy Bush References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: sidr@ietf.org Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 14:57:43 -0000 > nope. gains absolute zero replay protection. see my preso from VdeQ. I fail to see how this is possible. Please send a pointer. > but i am not really interested in the noise about beaconing. as i said > in VdeQ, the feature is nice but not all that important. You're saying replay protection isn't important? Russ From randy@psg.com Tue Nov 8 07:13:25 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930C221F8D12 for ; Tue, 8 Nov 2011 07:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YW1NWxi4fijF for ; Tue, 8 Nov 2011 07:13:25 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1C32821F8D0D for ; Tue, 8 Nov 2011 07:13:25 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RNnMa-0008Fk-B2; Tue, 08 Nov 2011 15:13:24 +0000 Date: Tue, 08 Nov 2011 16:13:23 +0100 Message-ID: From: Randy Bush To: Russ White In-Reply-To: <4EB94363.2090809@riw.us> References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com> <4EB94363.2090809@riw.us> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 15:13:25 -0000 >> nope. gains absolute zero replay protection. see my preso from VdeQ. > I fail to see how this is possible. Please send a pointer. from slide 10 A originates the announcement If everyone beacons, assume the beacon TTL applies only to that hop =20 B gets it from A, C gets it from B, D gets it from C D can keep sending the announcement, even though C=E2=80=99s TTL expired. = Oops! randy From randy@psg.com Tue Nov 8 07:14:53 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7225E21F8D0D for ; Tue, 8 Nov 2011 07:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P78s2+HjSDM4 for ; Tue, 8 Nov 2011 07:14:53 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 28E3121F8D07 for ; Tue, 8 Nov 2011 07:14:53 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RNnO0-0008GG-RC; Tue, 08 Nov 2011 15:14:53 +0000 Date: Tue, 08 Nov 2011 16:14:51 +0100 Message-ID: From: Randy Bush To: Russ White In-Reply-To: References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com> <4EB94363.2090809@riw.us> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 15:14:53 -0000 and, slide 11 So try believing minimum TTL in chain But are all redundant to the first, since if that one expires none of the others should even be sent An intermediate might want a lower one, in case its downstream link goes down, but why? The downstream neighbor will announce a different path, but to those further still downstream that is indistinguishable from many other causes of seeing a different path from your upstream And there's no real reason for an intermediate node to want to beacon because it has no skin in the game From jakob.heitz@ericsson.com Tue Nov 8 09:08:33 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3733D21F84BC for ; Tue, 8 Nov 2011 09:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6 X-Spam-Level: X-Spam-Status: No, score=-6 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ML+1WJss-ZAA for ; Tue, 8 Nov 2011 09:08:32 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2F03C21F88A0 for ; Tue, 8 Nov 2011 09:08:32 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pA8H8JFW018474; Tue, 8 Nov 2011 11:08:30 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.52]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 8 Nov 2011 12:08:25 -0500 From: Jakob Heitz To: "Sriram, Kotikalapudi" Date: Tue, 8 Nov 2011 12:08:58 -0500 Thread-Topic: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs Thread-Index: AcyeOQbCEwntjOzgQRicTW2pcj0liw== Message-ID: <92AA1C8B-7CDB-406E-AA83-7C1BCD83CB69@ericsson.com> References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 17:08:33 -0000 Proposal was 24 hour beacon timeout and 3 beacons per timeout. That makes 3= beacons per day. -- Jakob Heitz. On Nov 8, 2011, at 5:00 AM, "Sriram, Kotikalapudi" wrote: >>=20 >> ooc, in regards to the above: is there any detailed analysis of how much= extra overhead we can expect from these beacons if BGPSec were deployed un= iversally today? Specifically, the comment above, "an AS could cause the s= ame impact on the routing system by changing other route parameters at the = same frequency" seems to miss the point I think I see in the objection: wha= t if _every_ AS must do this all the time (not just a rogue, or select few)= . How much extra overhead would ensue if (say) someone took the current se= t of all ASes and prefixes and simulated the extra update traffic needed in= (say) a day? Maybe if we saw some numbers that told us how many additiona= l updates and how much additional bandwidth this approach would require in = a routing system like today's we could understand another aspect of much of= a shift we are talking about? >>=20 >=20 > Eric, >=20 > According to=20 > http://bgpupdates.potaroo.net/instability/bgpupd.html=20 > the current global BGP system produces > Average Prefixes per BGP Update: 2.24 > Average BGP Update Messages per second: 1.13 =20 > Average Prefix Updates per second: 2.53 > From this we can compute: > Average Prefix Updates per day =3D 218696 >=20 > Now if we consider a BGPSEC island of 100,000 participating prefixes > (multiple ISPs form a BGPSEC island and there is BGPSEC between > them and also in each ISP's entire customer cone): > With 24 hour beaconing interval, we would have: > Prefix Updates per Day =3D 100,000 (seen at each BGPSEC router) > BGPSEC Update Size =3D 420B (for ECDSA-256) > Average Bandwidth Required =3D 3.89 kbps (averaged over a day)=20 >=20 > Does this answer what you were asking for? >=20 > Sriram=20 >=20 >=20 >=20 > _______________________________________________ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From kotikalapudi.sriram@nist.gov Tue Nov 8 09:19:19 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296FD21F8B51 for ; Tue, 8 Nov 2011 09:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLH7otZ9l2Nl for ; Tue, 8 Nov 2011 09:19:18 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 545F521F8B4D for ; Tue, 8 Nov 2011 09:19:18 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 8 Nov 2011 12:19:12 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 8 Nov 2011 12:19:16 -0500 From: "Sriram, Kotikalapudi" To: Jakob Heitz Date: Tue, 8 Nov 2011 12:19:15 -0500 Thread-Topic: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs Thread-Index: AcyeOQbCEwntjOzgQRicTW2pcj0liwAAOQHw Message-ID: References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com> <92AA1C8B-7CDB-406E-AA83-7C1BCD83CB69@ericsson.com> In-Reply-To: <92AA1C8B-7CDB-406E-AA83-7C1BCD83CB69@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 17:19:19 -0000 Now the ops doc has much longer beaconing interval recommendations for what you may consider a normal prefix. http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-01#section-7 Normal Prefix: Most prefixes SHOULD announce with a signature validity of a week and beacon every three days. Sriram -----Original Message----- From: Jakob Heitz [mailto:jakob.heitz@ericsson.com] Sent: Tuesday, November 08, 2011 12:09 PM To: Sriram, Kotikalapudi Cc: Christopher Morrow; Eric Osterweil; sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs Proposal was 24 hour beacon timeout and 3 beacons per timeout. That makes 3 beacons per day. -- Jakob Heitz. From eosterweil@verisign.com Tue Nov 8 11:39:29 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2465B11E8086 for ; Tue, 8 Nov 2011 11:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAAsxwLQPMvM for ; Tue, 8 Nov 2011 11:39:28 -0800 (PST) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id DCE8411E8085 for ; Tue, 8 Nov 2011 11:39:27 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP; Tue, 08 Nov 2011 11:39:27 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id pA8JcZ4Y020809; Tue, 8 Nov 2011 14:38:35 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.35]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Nov 2011 14:38:35 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Tue, 8 Nov 2011 14:38:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> <3F1388E3-A694-42C9-AE2F-F12BF15DC86F@verisign.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 08 Nov 2011 19:38:35.0403 (UTC) FILETIME=[01572DB0:01CC9E4E] Cc: "sidr@ietf.org list" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 19:39:29 -0000 On Nov 7, 2011, at 6:38 PM, Stephen Kent wrote: > Eric, >=20 > I didn't miss your point; I just do not agree with it. I was noting = that > Terry suggested that a milestone doc ought to reflect input from the = CAs and > RPs, and that the NRO and IANA are reasonable candidates for such = input coordination. >=20 > You have said, repeatedly, that you feel that a global schedule for = alg transition is a terrible idea. You have explained why you believe = so. I have grave doubts about the high level scenario that you have = described. Your comments seem to ignore the fact that the transition = plan incorporates phases precisely to enable CAs and RPs to verify that = they have working code to deal with the new alg suite before the old one = is turned off. You postulate a major problem that precludes a = transition to a new alg Suite (presumably for Phase 4), but that phase = occurs only after CAs have been generating products and RPs have been = consuming them for some time. >=20 > This is not a productive discussion. Howdy Steve, Thanks for your response. Upon re-reading the exchange, I can see how = my statements might have come across as categorically against this approach. This was not my intention, so I'm sorry if that was the = impression I gave you. If the list (and you) would indulge me, I'd like to try a (hopefully) more constructive tack: I outlined a few questions = that arose in my reading of the draft, and then made a handful of = suggestions. Just to be sure my thinking was clear (well, everything is relative: as = clear as I ever get), I re-read the draft. In doing so, I tried to refactor my concerns in some more clarifying questions that jumped out = at me: 1 - In the draft, there is discussion of the global agreement to move to = algorithm B. Who ensures the global agreement of B, and who chooses and ensures agreement of the various dates? 2 - (Double checking that I have read this right), if the motivation for = an algorithm roll is discovery of a weakness in the current algo, no CA can roll until this top-down process reaches them, right (months = or years)? I see this is broached in Section 11, but it doesn't seem to be answered there? It sounds like the authors don't intend to = address this any further than acknowledging the suboptimality of this approach? 3 - Section 11 also prompted another question I had throughout: what = happens if a CA doesn't meet these deadlines? It seems like that CA is simply orphaned and cannot participate in routing anymore (until = they catch back up)? =46rom these three questions, I came to the following clarification = suggestions: 1 - I see the phases in this draft as defining a formal process. = However, I don't see any error-legs (i.e. what happens if there needs to be an abort, rollback, whatever you want to call it). I think it is = important to outline how this process can react if there are any unforeseen failures at each phase. I'm not sure that we need to be = terribly specific, but perhaps we can agree that _something_ could go wrong and cause the need for an abort? I think this is quite common in = process-specifications, unless we think nothing will ever go wrong in this process? :) 2 - Related to the above, I would imagine (but maybe this is just me?) = that in the event of a failure at one phase or another, there may need to be a rollback procedure specified. 3 - I think a lot of complexity in the overall draft (and my above = comments) could be addressed by allowing CAs to choose their own algorithms and their own schedules. Could this be considered? I recall = we discussed how this might negatively affect the performance of the current design's complexity. It's possible that we will just simply = come to loggerheads here, but (design issues aside) do people think CA operators should have the ability to protect themselves as soon as = they can move to a new algo? 4 - Finally, there is a note that all algorithms must be specified in = I-D.ietf-sidr-rpki-algs. While I am not challenging that, I would like to point out that having an analogous requirement in DNSSEC made = life a little challenging to add new algos (specifically GOST) without a lot of people trying to assess the algo's worthiness w/i the IETF. I = thought, though I could be mistaken, that several people lamented having that requirement. So, perhaps it would make sense to soften it = here? Thanks, Eric From weiler@watson.org Tue Nov 8 11:49:57 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A2211E80F6 for ; Tue, 8 Nov 2011 11:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEFPmAEOmJTt for ; Tue, 8 Nov 2011 11:49:57 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id E7AA011E8085 for ; Tue, 8 Nov 2011 11:49:56 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id pA8JnuLk011214 for ; Tue, 8 Nov 2011 14:49:56 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id pA8Jntgq011210 for ; Tue, 8 Nov 2011 14:49:56 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 8 Nov 2011 14:49:55 -0500 (EST) From: Samuel Weiler To: sidr@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 08 Nov 2011 14:49:56 -0500 (EST) Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 19:49:57 -0000 This document is basically ready for publication. While it is painfully long, it is arguably one of the better written documents this WG has produced. My thanks to the editors for their efforts. I am uneasy with the limitations imposed by this mechanism, but I have nothing better to suggest. Let's go forward with this general approach. On to specifics: I am persuaded by Terry's argument that it may not be appropriate to publish hard dates for later steps. Please change the doc accordingly. And two very minor things: Near the end of section 2, there appears to be a duplication: This document does not specify any algorithm suite. This document does not specify any algorithm suite per se. And I'm unconvinced of the need for this particular limitation: All Dates MUST be represented using the local UTC date-time format specified in [RFC3339]. While the steps in this process are ordered, the timeliness of them need not be so precise that we need to restrict how we write the date. -- Sam From Sandra.Murphy@cobham.com Tue Nov 8 15:25:47 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D37A1F0C70 for ; Tue, 8 Nov 2011 15:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RupuJGWbc2D for ; Tue, 8 Nov 2011 15:25:46 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id DD0CC1F0C6F for ; Tue, 8 Nov 2011 15:25:45 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id pA8NPiiA005737 for ; Tue, 8 Nov 2011 17:25:44 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id pA8NPi0n000652 for ; Tue, 8 Nov 2011 17:25:44 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com (157.185.81.187) by Hermes.columbia.ads.sparta.com (157.185.80.107) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 8 Nov 2011 18:25:38 -0500 Date: Tue, 8 Nov 2011 18:25:33 -0500 From: Sandra Murphy To: In-Reply-To: Message-ID: References: X-X-Sender: sandy@hermes.columbia.ads.sparta.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed Subject: [sidr] sidr move to Tue 1300 (was Re: possible wg time slot change) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 23:25:47 -0000 PKIX did cancel their 1300 Tue time slot yesterday. The routing ADs approved moving the sidr wg to that time slot and requested the secretariat to make the move. (I presume that makes it a done deal.) This all came up after the final agenda was printed and the move is not yet reflected on the agenda page. So you might need to keep track on your own. --Sandy, speaking as wg chair On Fri, 28 Oct 2011, Sandra Murphy wrote: > To accommodate our Tech Advisor, we are investigating a sidr move to an early > day in the week. > > There's a good possibility that we'll move to Mon afternoon in place of cuss > or opsec. That would mean that an hour of the agenda would still be on Fri. > > There's a remote possibility that we'll move the entire agenda to Tue at 1pm > if another wg cancels. > > Moving pends approval of respective ADs etc. > > But thought you might like notice. > > --Sandy > > From kent@bbn.com Tue Nov 8 15:44:19 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF84C1F0C70 for ; Tue, 8 Nov 2011 15:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.43 X-Spam-Level: X-Spam-Status: No, score=-106.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gc1qZT9fu4oC for ; Tue, 8 Nov 2011 15:44:18 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 300A921F8540 for ; Tue, 8 Nov 2011 15:44:18 -0800 (PST) Received: from dhcp89-089-006.bbn.com ([128.89.89.6]:49186) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RNvKz-000Dqe-2c; Tue, 08 Nov 2011 18:44:17 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> <3F1388E3-A694-42C9-AE2F-F12BF15DC86F@verisign.com> Date: Tue, 8 Nov 2011 18:37:38 -0500 To: Eric Osterweil From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org list" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 23:44:19 -0000 Eric, Thanks for your comments. responses are inline. >... >1 - In the draft, there is discussion of the global agreement to >move to algorithm B. Who ensures the global agreement of B, and who >chooses >and ensures agreement of the various dates? the IETF is responsible for the alg selection, just as it has been for other algs used with all other IETF standard protocols. Based on Terry's comments, I think we will state that the RFC defining the transition dates will be coordinated with the NRO and IANA. >2 - (Double checking that I have read this right), if the motivation >for an algorithm roll is discovery of a weakness in the current algo, >no CA can roll until this top-down process reaches them, right >(months or years)? I see this is broached in Section 11, but it >doesn't seem >to be answered there? It sounds like the authors don't intend to >address this any further than acknowledging the suboptimality of this >approach? The motivation for alg transition is anticipated weakness in the current alg suite, more so than a sudden discovery of a vulnerability. Althoygh there have been major headlines about alg breaks, these are usually FUD, and do not motivate an immediate transition to a new alg suite. So, no we are not proposing a process that deals with a sudden alg break. >3 - Section 11 also prompted another question I had throughout: what >happens if a CA doesn't meet these deadlines? It seems like that >CA is simply orphaned and cannot participate in routing anymore >(until they catch back up)? It's easier to discuss this if you pick a specific phase. Which one did you have in mind? > >From these three questions, I came to the following clarification >suggestions: >1 - I see the phases in this draft as defining a formal process. >However, I don't see any error-legs (i.e. what happens if there >needs to >be an abort, rollback, whatever you want to call it). I think it is >important to outline how this process can react if there are any >unforeseen failures at each phase. I'm not sure that we need to be >terribly specific, but perhaps we can agree that _something_ could go >wrong and cause the need for an abort? I think this is quite common >in process-specifications, unless we think nothing will ever go wrong >in this process? :) What one might would do is phase specific. But, in general, the timeline could be pushed back if there is a good reason to do so. I thin terry';s suggestion helps in this regard. If we view the NRO as representing the RIRs, and the RIRs as representing ISPs, then there is a path for a CA or RP that has a problem to make that problem known, and addressed. >2 - Related to the above, I would imagine (but maybe this is just >me?) that in the event of a failure at one phase or another, >there may need to be a rollback procedure specified. I'm not sure that there is a need for a rollback, per se. Pick a phase and a failure mode as an example as we can explore that issue. >3 - I think a lot of complexity in the overall draft (and my above >comments) could be addressed by allowing CAs to choose their own >algorithms and their own schedules. Could this be considered? I >recall we discussed how this might negatively affect the performance >of >the current design's complexity. It's possible that we will just >simply come to loggerheads here, but (design issues aside) do people >think >CA operators should have the ability to protect themselves as soon >as they can move to a new algo? One cannot allow each CA to choose it's own set of algs, because that local choice has an impact on ALL RPs. That's what economists call externalization, and it's a bad thing. Having each CA choose it's own schedule is also a non -starter. Geoff Huston observed that unless we adopt a top-down transition plan, the repository could grow exponentially! That's an unreasonable burden. With a top-down plan CAs have limits imposed on them, already, i.e., a lower tier CA cannot switch to a new alg until it's parents support the new alg. >4 - Finally, there is a note that all algorithms must be specified >in I-D.ietf-sidr-rpki-algs. While I am not challenging that, I would >like to point out that having an analogous requirement in DNSSEC >made life a little challenging to add new algos (specifically GOST) >without a >lot of people trying to assess the algo's worthiness w/i the IETF. >I thought, though I could be mistaken, that several people lamented >having that requirement. So, perhaps it would make sense to soften it here? DNSSEC was initially less rigorous in its alg criteria, and the result was not great. We are avoiding those problems. Steve From Sandra.Murphy@cobham.com Wed Nov 9 10:44:28 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A91521F84CD for ; Wed, 9 Nov 2011 10:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VE9aBxV8DHJ for ; Wed, 9 Nov 2011 10:44:27 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 794EB21F86A0 for ; Wed, 9 Nov 2011 10:44:27 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id pA9Ii3U3013240 for ; Wed, 9 Nov 2011 12:44:08 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id pA9Ii3TE022933 for ; Wed, 9 Nov 2011 12:44:03 -0600 Received: from SMURPHY-LT.columbia.ads.sparta.com (157.185.81.187) by Hermes.columbia.ads.sparta.com (157.185.80.107) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 9 Nov 2011 13:44:02 -0500 Date: Wed, 9 Nov 2011 13:43:57 -0500 From: Sandra Murphy To: Message-ID: X-X-Sender: sandy@hermes.columbia.ads.sparta.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed Subject: [sidr] Etherpad for collaborative note-taking (fwd) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 18:44:28 -0000 This is an interesting new tool. Take a look and see if you think it would be easy and effect to use during the upcoming meeting. The url for the sidr page is http://tools.ietf.org/wg/sidr/minutes. --Sandy, speaking as wg chair ---------- Forwarded message ---------- Date: Wed, 9 Nov 2011 05:43:24 -0500 From: Henrik Levkowetz To: WG Chairs Subject: Etherpad for collaborative note-taking Hi, Acting on a recent suggestion from Peter Saint-Andre (on ietf@ietf.org), I've now set up an instance of Etherpad Lite (http://etherpad.org/) on one of the tools servers, and used it to make a collaborative notes document available for all WGs with a posted agenda for IETF-82. You'll find it both linked in and embedded in the minutes page for your WG on tools.ietf.org; for an example see http://tools.ietf.org/wg/clue/minutes The note documents will be visible on the minutes page until you submit official minutes for the meeting, at which time they will be replaced by the minutes. The etherpad documents will still be accessible directly at the etherpad URL for some time after the meeting, but will be archived and replaced by new empty documents before the next meeting. Comments and suggestions are welcome! Best regards, Henrik From kent@bbn.com Wed Nov 9 10:57:36 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61E311E8087 for ; Wed, 9 Nov 2011 10:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.152 X-Spam-Level: X-Spam-Status: No, score=-106.152 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81ZouMVvAfaC for ; Wed, 9 Nov 2011 10:57:35 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBAA11E8083 for ; Wed, 9 Nov 2011 10:57:35 -0800 (PST) Received: from dhcp89-089-006.bbn.com ([128.89.89.6]:49159) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RODL4-0001Xh-Tw; Wed, 09 Nov 2011 13:57:35 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F6025FEE@Hermes.columbia.ads.sparta.com> Date: Wed, 9 Nov 2011 13:42:30 -0500 To: Brian Dickson From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-891257443==_ma============" Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 18:57:36 -0000 --============_-891257443==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 1:27 AM -0500 11/8/11, Brian Dickson wrote: >... >I do not support adoption of this document in its current form. > >The main reasons have to do with fundamental aspects which at a high >level have been addressed by my colleagues, so, this is a Verisign critique, provided by you, Eric, and Danny? >Here's why: >- everybody is a CA. Both the "root" of the INR tree (ICANN/IANA), >plus the RIRs, etc., down to the publishers of EE certs. yes, essentially every actor in the RPKI is both a CA and an RP. >- each CA publishes its policy via a CPS (it's a SHOULD, but >functionally a MUST for RPs to be able to understand what a CA >publishes.) small ISPs and orgs that have address space probably will not bother with a CPS, which is why it is a SHOULD, not a MUST. In a typical PKI context, a CPS primarily benefits the subjects to whom certs are issued; RPs also are potential CPS consumers. In the RPKI, a "keaf" CA issues certs to itself, so a CPS is not of much interest for the first class of consumers. In the RPLI one does not get to shop around to choose a CA, so RPs don't need much from a CPS. >- Each CPS specifies the OID of the corresponding CP there is just one CP. not clear form your statement if thatr ws clear. >- Each CP refers to the corresponding policy for algorithms there is only one policy (CP) for the RPKI, and it specifies algs via a reference to an alg spec. so, I am not sure what you have in mind here. >- Algorithms themselves have OIDs and are referenced as such in certs yes. >- Every cert also specifies the OID of the CP itself (which embodies >the rules for allowed algorithms) yes. >So while the first revision of the CP insists on only one algorithm >for pub/private keys, and one algorithm for hashes, it explicitly >calls out that these are expected to change. yes. >In changing allowed algorithms, it can reasonably be inferred that CPs >could be issued which increase the _number_ of allowed algoriths of >both types beyond one. there is only one CP. >And similarly, the methodology demonstrated by key rollover has local >scope. There is no requirement that children do anything at all when a >parent executes a key roll. _This is by design_. yes, this is by design, but is irrelevant to the the alg transition design, which has global impact (on all RPs). > >So the analogous high-level design for agility SHOULD be as follows: >- new CP documents may be published, with new OIDs as I mentioned above, there is one CP for the RPKI. When you suggest multile CPs, are you thinking of them on a per CA basis, or RPKI-wide? >- ONLY when a CA with a given CPS decides to change CP does that CA >need to execute a locally-significant key+alg roll see question above. also, unlike key roll, an alg roll affects ALL RPs, which is why the analogy between the two procedures is bad. Also, note my 'reply to Brian re the top-dowen deployment model that the Wg adopted, to avoid exponential growth in the repository system. >- The CA would issue new certs with the new CP which itself lists >additional algorithms ibid. >- The same procedure would be executed in multiple phases - issue new >child certs published under the old main cert; move them to the new >cert, rewriting/overwriting in the same location ibid. >This could be handled gracefully by having two CPs - one CP having the >additional algorithm(s), and subsequently another CP with the new but >minus the old. not graceful re repository growth, and impact on RPs. >This mechanism could be used to introduce new algorithms without >requiring retiring specific old algorithms. The two actions - adding >and removing - are in fact independent, beyond the requirement that >there be at least one algorithm (which goes without saying, really). >The only other requirement is that the issued certs have algorithms >consistent with the specified CP (OID) attached to the cert. there needs to be one alg that ALL RPs can deal with at all times. Also, unlike key roll, when a CA wants to have a new cert with a public key using a new alg, its parent MUST be able to support that alg, because of the PoP requirement. >I may be completely off the mark, but this would seem to be much more >in line with the whole manner in which algorithms, policies, resource >objects, etc., have been separated out and linked by normative >reference. I do not agree. >Perhaps we could get Geoff Huston to comment on my interpretation of >the CP/CPS/alg interaction and explicit/implicit rules? >Is it intended that CAs have a uniform hierarchy using exactly one >algorithm set, or is it intended that each CA be able to specify (via >CPS + CP) the set of algorithms it supports, with the initial CP >document being the minimum acceptable algorithm set? This text suggests that you believe there is on CP per CA, vs. a system-wide CP. The architecture is the latter. Also, while I respect Goeff, why is your question directed to him? I am a co-author of the CP, the arch, and the key roll and the alg roll docs :-). Steve --============_-891257443==_ma============ Content-Type: text/html; charset="us-ascii" Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03
At 1:27 AM -0500 11/8/11, Brian Dickson wrote:
...

I do not support adoption of this document in its current form.

The main reasons have to do with fundamental aspects which at a high
level have been addressed by my colleagues,

so, this is a Verisign critique, provided by you, Eric, and Danny?

Here's why:
- everybody is a CA. Both the "root" of the INR tree (ICANN/IANA),
plus the RIRs, etc., down to the publishers of EE certs.

yes, essentially every actor in the RPKI is both a CA and an RP.

- each CA publishes its policy via a CPS (it's a SHOULD, but
functionally a MUST for RPs to be able to understand what a CA
publishes.)

small ISPs and orgs that have address space probably will not bother with a CPS, which is why it is a SHOULD, not a MUST. In a typical PKI context, a CPS primarily benefits the subjects to whom certs are issued; RPs also are potential CPS consumers.  In the RPKI, a "keaf" CA issues certs to itself, so a CPS is not of much interest for the first class of consumers. In the RPLI one does not get to shop around to choose a CA, so RPs don't need much from a CPS.
 
- Each CPS specifies the OID of the corresponding CP

there is just one CP. not clear form your statement if thatr ws clear.

- Each CP refers to the corresponding policy for algorithms

there is only one policy (CP) for the RPKI, and it specifies algs via a reference to an alg spec. so, I am not sure what you have in mind here.

- Algorithms themselves have OIDs and are referenced as such in certs

yes.
- Every cert also specifies the OID of the CP itself (which embodies
the rules for allowed algorithms)

yes.

So while the first revision of the CP insists on only one algorithm
for pub/private keys, and one algorithm for hashes, it explicitly
calls out that these are expected to change.

yes.
In changing allowed algorithms, it can reasonably be inferred that CPs
could be issued which increase the _number_ of allowed algoriths of
both types beyond one.

there is only one CP.

And similarly, the methodology demonstrated by key rollover has local
scope. There is no requirement that children do anything at all when a
parent executes a key roll. _This is by design_.

yes, this is by design, but is irrelevant to the the alg transition design, which has global impact (on all RPs).


So the analogous high-level design for agility SHOULD be as follows:
- new CP documents may be published, with new OIDs

as I mentioned above, there is one CP for the RPKI. When you suggest multile
CPs, are you thinking of them on a per CA basis, or RPKI-wide?

- ONLY when a CA with a given CPS decides to change CP does that CA
need to execute a locally-significant key+alg roll

see question above. also, unlike key roll, an alg roll affects ALL RPs,
which is why the analogy between the two procedures is bad. Also, note my
'reply to Brian re the top-dowen deployment model that the Wg adopted, to avoid
exponential growth in the repository system.

- The CA would issue new certs with the new CP which itself lists
additional algorithms

ibid.

- The same procedure would be executed in multiple phases - issue new
child certs published under the old main cert; move them to the new
cert, rewriting/overwriting in the same location

ibid.
This could be handled gracefully by having two CPs - one CP having the
additional algorithm(s), and subsequently another CP with the new but
minus the old.

not graceful re repository growth, and impact on RPs.

This mechanism could be used to introduce new algorithms without
requiring retiring specific old algorithms. The two actions - adding
and removing - are in fact independent, beyond the requirement that
there be at least one algorithm (which goes without saying, really).
The only other requirement is that the issued certs have algorithms
consistent with the specified CP (OID) attached to the cert.

there needs to be one alg that ALL RPs can deal with at all times.  Also,
unlike key roll, when a CA wants to have a new cert with a public key
using a new alg, its parent MUST be able to support that alg, because of
the PoP requirement.

I may be completely off the mark, but this would seem to be much more
in line with the whole manner in which algorithms, policies, resource
objects, etc., have been separated out and linked by normative
reference.

I do not agree.

Perhaps we could get Geoff Huston to comment on my interpretation of
the CP/CPS/alg interaction and explicit/implicit rules?
Is it intended that CAs have a uniform hierarchy using exactly one
algorithm set, or is it intended that each CA be able to specify (via
CPS + CP)  the set of algorithms it supports, with the initial CP
document being the minimum acceptable algorithm set?

This text suggests that you believe there is on CP per CA, vs. a
system-wide CP. The architecture is the latter.  Also, while I respect
Goeff, why is your question directed to him? I am a co-author of the CP,
the arch, and the key roll and the alg roll docs :-).

Steve
--============_-891257443==_ma============-- From kent@bbn.com Wed Nov 9 10:57:50 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373FC11E809A for ; Wed, 9 Nov 2011 10:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.443 X-Spam-Level: X-Spam-Status: No, score=-106.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-74zZ0II9p9 for ; Wed, 9 Nov 2011 10:57:49 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C315111E8083 for ; Wed, 9 Nov 2011 10:57:49 -0800 (PST) Received: from dhcp89-089-006.bbn.com ([128.89.89.6]:49159) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RODL4-0001Xh-By; Wed, 09 Nov 2011 13:57:34 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <10A3F6FD-1392-4E6E-A048-A8EED1E8C329@apnic.net> References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> <10A3F6FD-1392-4E6E-A048-A8EED1E8C329@apnic.net> Date: Wed, 9 Nov 2011 13:33:50 -0500 To: Geoff Huston From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 18:57:50 -0000 At 3:09 PM +1100 11/5/11, Geoff Huston wrote: >On 05/11/2011, at 12:34 PM, Randy Bush wrote: > >>> I think the distinction between a leak and something more intentional >>> s a matter of policy. Knowing the policy associated with the >>> adjacencies that an AS is leaking over would allow leaked >>> announcements to be identified >> >> o We can not know intent, should Mary have announced the prefix to Bob > > >I disagree with this assertion of impossibility. The intention of the routing >policy databases in their various flavours and incarnations was to publish >intent and allow others to filter based on intent. Geoff, I have been told that the lack of widely available, reliable IRR data out side of the RIPE region is due, in part, to a reluctance by operators to publish all of these details. If that is true, then it argues against assuming the existence of such data on a global basis. Steve From gih@apnic.net Wed Nov 9 11:56:16 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E5D21F84AF for ; Wed, 9 Nov 2011 11:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.086 X-Spam-Level: X-Spam-Status: No, score=-98.086 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_AU=0.327, HOST_MISMATCH_AU=2.444, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YreEQa3XLYrn for ; Wed, 9 Nov 2011 11:56:16 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id AEEAE21F84B1 for ; Wed, 9 Nov 2011 11:56:15 -0800 (PST) Received: from [192.168.2.5] (d110-33-203-45.mas801.nsw.optusnet.com.au [110.33.203.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 59B28B675F; Thu, 10 Nov 2011 05:56:14 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Thu, 10 Nov 2011 06:56:12 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <60C11709-5D46-474A-A4DB-ADE0675E73D8@apnic.net> References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> <10A3F6FD-1392-4E6E-A048-A8EED1E8C329@apnic.net> To: Stephen Kent X-Mailer: Apple Mail (2.1251.1) Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 19:56:16 -0000 On 10/11/2011, at 5:33 AM, Stephen Kent wrote: > At 3:09 PM +1100 11/5/11, Geoff Huston wrote: >> On 05/11/2011, at 12:34 PM, Randy Bush wrote: >>=20 >>>> I think the distinction between a leak and something more = intentional >>>> s a matter of policy. Knowing the policy associated with the >>>> adjacencies that an AS is leaking over would allow leaked >>>> announcements to be identified >>>=20 >>> o We can not know intent, should Mary have announced the prefix to = Bob >>=20 >>=20 >> I disagree with this assertion of impossibility. The intention of the = routing >> policy databases in their various flavours and incarnations was to = publish >> intent and allow others to filter based on intent. >=20 > Geoff, >=20 > I have been told that the lack of widely available, reliable IRR data=20= > out side of the RIPE region is due, in part, to a reluctance by=20 > operators to publish all of these details. If that is true, then it=20= > argues against assuming the existence of such data on a global basis. >=20 > Steve I did not claim it existed - I merely disagreed with the claim of its=20 impossibility of existence. In the same way that the only way you can eliminate the "unknown" = validation outcome is to achieve universal adoption of the generation of = credentials, the general visibility of intent relies on universal adoption on the = generation of routing policy. It is not impossible per se, it just relies on = universal adoption! In the case of the efforts relating to RPSL, reality has not achieved = such targets of universal adoption, as you point out. In the case of the efforts relating to the BGP security mechanisms you = are working on, it is an open issue as to how many folk would adopt it, but our = experiences of other technologies, including 4 byte ASN support indicate that = universal adoption is an extremely challenging objective. =20 Geoff From brian.peter.dickson@gmail.com Wed Nov 9 12:07:27 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F95F1F0C4A for ; Wed, 9 Nov 2011 12:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEfTK3nKQqZO for ; Wed, 9 Nov 2011 12:07:27 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id E51391F0C41 for ; Wed, 9 Nov 2011 12:07:26 -0800 (PST) Received: by faas12 with SMTP id s12so2454543faa.31 for ; Wed, 09 Nov 2011 12:07:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cssFrTj0EKdN54JJeN7Lm+k5hRLL53yx4bCJVsF/PNU=; b=NQurJ+TQykt/l5ilUdf85qB9Hfl7d6byQhLH9TeW3no7XChhPHSjldou8PLfDLD+yG FYbB6YaT/Jdd3LqeKgMxBJefYNTt6NiST4VYMMYLMBEvuG+uhEpb3v75F6k0TX3JEQoY A1OKAFA3H5cYGj8LXnhGt63RRfJDS+iCEw2Gg= MIME-Version: 1.0 Received: by 10.223.94.143 with SMTP id z15mr6853937fam.32.1320869246067; Wed, 09 Nov 2011 12:07:26 -0800 (PST) Received: by 10.223.54.15 with HTTP; Wed, 9 Nov 2011 12:07:25 -0800 (PST) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F6025FEE@Hermes.columbia.ads.sparta.com> Date: Wed, 9 Nov 2011 15:07:25 -0500 Message-ID: From: Brian Dickson To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 20:07:27 -0000 On Wed, Nov 9, 2011 at 1:42 PM, Stephen Kent wrote: > At 1:27 AM -0500 11/8/11, Brian Dickson wrote: > > ... > > I do not support adoption of this document in its current form. > > The main reasons have to do with fundamental aspects which at a high > > level have been addressed by my colleagues, > > so, this is a Verisign critique, provided by you, Eric, and Danny? Respectfully, Stephen, I would ask that you not infer anything along these lines. The IETF is very clear on participation being an individual activity, regardless of $day_job. In addition to this _not_ being the case, I _personally_ consider this both highly inappropriate at a professional level, and bordering on _ad_hominem_, something that really has no place in WG mailing-list discussions. I would ask that you seriously consider whether an apology for your comment is appropriate. As for "colleague", I meant within the WG, as in "collegial". If I had meant to say "co-worker", I would have said "co-worker". Any similarity between our concerns is entirely due to similarity in operational experiences in a variety of venues, at a variety of $day_jobs. I'll address the content-oriented portion of your email in a separate message. Brian - not using any email-address that would suggest affiliation - From eosterweil@verisign.com Wed Nov 9 12:37:17 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0490011E80AD for ; Wed, 9 Nov 2011 12:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cd2wwfPwuSwt for ; Wed, 9 Nov 2011 12:37:16 -0800 (PST) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0286711E8080 for ; Wed, 9 Nov 2011 12:37:15 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKTrrkbg6ivRGOebjlHaEzVH85SXBIZnJg@postini.com; Wed, 09 Nov 2011 12:37:16 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id pA9Kb1Mk027860; Wed, 9 Nov 2011 15:37:02 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.131.30.124]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 15:37:01 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Wed, 9 Nov 2011 15:37:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <32DF728C-A96A-435D-A54E-7626C2577F04@verisign.com> References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com> <92AA1C8B-7CDB-406E-AA83-7C1BCD83CB69@ericsson.com> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 09 Nov 2011 20:37:01.0189 (UTC) FILETIME=[555D6B50:01CC9F1F] Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 20:37:17 -0000 Hey Sriram, Russ, and Jakob, Thanks for the #s. I think I get the general notion that adding n = updates per day per prefix equals (n * #prefixes)/1. :) I guess my = question was kinda vague, sorry. Upon reexamination, I see that I said = "overhead" without being specific. Since we can use the updates that = are generated today to measure how much (for example) bandwidth is = already needed, can we calculate how much extra bandwidth universal = deployment would mean? Also, perhaps this would be most informative in = the form of a ratio (i.e. a factor of $x$ increase). That way, when = people look at events like the one that the "General Internet = Instability" thread that just happened on NANOG refer to, they can gauge = the update amplification that was seen against what _would_ be seen = given bgpsec. I think this actually kind of came up on nanog, so it = seems like maybe it would be a relevant thing to look at here? Anyway, I guess I was mostly just curious about what kinds of = evaluations have been done, thanks. :) Eric On Nov 8, 2011, at 12:19 PM, Sriram, Kotikalapudi wrote: > Now the ops doc has much longer beaconing interval recommendations > for what you may consider a normal prefix. >=20 > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-01#section-7 >=20 > Normal Prefix: Most prefixes SHOULD announce with a signature > validity of a week and beacon every three days. >=20 > Sriram >=20 > -----Original Message----- > From: Jakob Heitz [mailto:jakob.heitz@ericsson.com]=20 > Sent: Tuesday, November 08, 2011 12:09 PM > To: Sriram, Kotikalapudi > Cc: Christopher Morrow; Eric Osterweil; sidr wg list > Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs >=20 > Proposal was 24 hour beacon timeout and 3 beacons per timeout. That = makes 3 beacons per day. >=20 > -- > Jakob Heitz. >=20 >=20 From eosterweil@verisign.com Wed Nov 9 12:39:22 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26C011E80AF for ; Wed, 9 Nov 2011 12:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUwR2eQ8+wNy for ; Wed, 9 Nov 2011 12:39:21 -0800 (PST) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 72DF111E8080 for ; Wed, 9 Nov 2011 12:39:21 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKTrrk87Uuvs6a03RV232h0YJ8hC+aI9mH@postini.com; Wed, 09 Nov 2011 12:39:21 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id pA9KdEdr027928; Wed, 9 Nov 2011 15:39:14 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.131.30.124]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 15:39:13 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Wed, 9 Nov 2011 15:39:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> <3F1388E3-A694-42C9-AE2F-F12BF15DC86F@verisign.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 09 Nov 2011 20:39:13.0800 (UTC) FILETIME=[A4684080:01CC9F1F] Cc: "sidr@ietf.org list" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 20:39:22 -0000 Hey Steve, On Nov 8, 2011, at 6:37 PM, Stephen Kent wrote: >> ... >> 1 - In the draft, there is discussion of the global agreement to move = to algorithm B. Who ensures the global agreement of B, and who chooses >> and ensures agreement of the various dates? >=20 > the IETF is responsible for the alg selection, just as it has been for = other algs used with all other IETF standard protocols. Based on Terry's = comments, I think we will state that the RFC defining the transition = dates will be coordinated with the NRO and IANA. Kewl, will look at the next version, thanks! >=20 >> 2 - (Double checking that I have read this right), if the motivation = for an algorithm roll is discovery of a weakness in the current algo, >> no CA can roll until this top-down process reaches them, right = (months or years)? I see this is broached in Section 11, but it doesn't = seem >> to be answered there? It sounds like the authors don't intend to = address this any further than acknowledging the suboptimality of this >> approach? >=20 > The motivation for alg transition is anticipated weakness in the = current alg suite, more so than a sudden discovery of a vulnerability. = Althoygh there have been major headlines about alg breaks, these are = usually FUD, and do not motivate an immediate transition to a new alg = suite. So, no we are not proposing a process that deals with a sudden = alg break. k. >=20 >> 3 - Section 11 also prompted another question I had throughout: what = happens if a CA doesn't meet these deadlines? It seems like that >> CA is simply orphaned and cannot participate in routing anymore = (until they catch back up)? >=20 > It's easier to discuss this if you pick a specific phase. Which one = did you have in mind? OK. For this particular question, I think I understood the draft to be = saying that at the end of phase 4, there may be fewer verified entities = in the global system (this was discussed in the last paragraph of = Section 11). I believe the implication is that if any CA doesn't keep = up (so to speak) they are considered invalid and therefore would be = un-routable? >=20 >> >=46rom these three questions, I came to the following clarification = suggestions: >> 1 - I see the phases in this draft as defining a formal process. = However, I don't see any error-legs (i.e. what happens if there needs to >> be an abort, rollback, whatever you want to call it). I think it is = important to outline how this process can react if there are any >> unforeseen failures at each phase. I'm not sure that we need to be = terribly specific, but perhaps we can agree that _something_ could go >> wrong and cause the need for an abort? I think this is quite common = in process-specifications, unless we think nothing will ever go wrong >> in this process? :) >=20 > What one might would do is phase specific. But, in general, the = timeline could be pushed back if there is a good reason to do so. I thin = terry';s suggestion helps in this regard. If we view the NRO as = representing the RIRs, and the RIRs as representing ISPs, then there is = a path for a CA or RP that has a problem to make that problem known, and = addressed. I think this needs to be codified for each phase in the draft. This = would seem to be a simple necessity that comes from defining a formal = process. >=20 >> 2 - Related to the above, I would imagine (but maybe this is just = me?) that in the event of a failure at one phase or another, >> there may need to be a rollback procedure specified. >=20 > I'm not sure that there is a need for a rollback, per se. Pick a = phase and a failure mode as an example as we can explore that issue. As per the above, I think each phase should define its starting = requirements (which I think are there), and what to do if its success = requirements are not met (exceptions, error legs, etc). I don't think = we need to rathole any strawmen to agree that it is possible that this = process may need to be aborted (even if only in very extremely rare = cases), and this document should detail how this will be done at each = phase. Indeed, I don't think this document should even try to enumerate = the specific types of failures. Rather, it should just tell people what = to do if a failure is deemed to have occurred. >=20 >> 3 - I think a lot of complexity in the overall draft (and my above = comments) could be addressed by allowing CAs to choose their own >> algorithms and their own schedules. Could this be considered? I = recall we discussed how this might negatively affect the performance of >> the current design's complexity. It's possible that we will just = simply come to loggerheads here, but (design issues aside) do people = think >> CA operators should have the ability to protect themselves as soon as = they can move to a new algo? >=20 > One cannot allow each CA to choose it's own set of algs, because that = local choice has an impact on ALL RPs. That's what economists call = externalization, and it's a bad thing. Having each CA choose it's own = schedule is also a non -starter. Geoff Huston observed that unless we = adopt a top-down transition plan, the repository could grow = exponentially! That's an unreasonable burden. With a top-down plan CAs = have limits imposed on them, already, i.e., a lower tier CA cannot = switch to a new alg until it's parents support the new alg. Hmm, I think there might be a bit of an oversimplification in this = perspective. The "externalization" you're describing sounds a lot like = an operational entity's right to govern their own operational choices. = In other words, regardless of whether this is a "bad" thing or not, = we've already got it now. Is trying to legislate a new operational = model that supplants an existing one the job of this draft? Does the exponential growth come from the need for a predecessor to = necessarily employ the union of all crypto algos that exist in the = hierarchy below them? I don't think that should be a requirement here = (perhaps exactly for the reason you just mentioned). Why can't a = cryptographic delegation chain be composed of heterogeneous algos? It = solves this complexity problem quite elegantly. One might even call it = algorithm agility... Sorry, I couldn't help adding some levity... :-P >=20 >> 4 - Finally, there is a note that all algorithms must be specified in = I-D.ietf-sidr-rpki-algs. While I am not challenging that, I would >> like to point out that having an analogous requirement in DNSSEC made = life a little challenging to add new algos (specifically GOST) without a >> lot of people trying to assess the algo's worthiness w/i the IETF. I = thought, though I could be mistaken, that several people lamented >> having that requirement. So, perhaps it would make sense to soften = it here? >=20 > DNSSEC was initially less rigorous in its alg criteria, and the result = was not great. We are avoiding those problems. Could you elaborate please? Eric= From brian.peter.dickson@gmail.com Wed Nov 9 13:44:28 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4869211E80AF for ; Wed, 9 Nov 2011 13:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.969 X-Spam-Level: X-Spam-Status: No, score=-2.969 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpAMEkQ3O0GT for ; Wed, 9 Nov 2011 13:44:08 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id A274C11E8093 for ; Wed, 9 Nov 2011 13:44:07 -0800 (PST) Received: by faas12 with SMTP id s12so2537932faa.31 for ; Wed, 09 Nov 2011 13:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=G/G0UGskTZHhEyxmTmMQej7seBAoZtMI+t7Tw8+ZPBo=; b=PBZidyOaRffEjS8I19DzCsFQT1mUsYGSdg+M3ee0iVahBDgy+O/p2q4WgsV78+m6fg HOjEFpzmdgGfMOKZnZktmyWlC6h6yudZbc0MLX6eKWYOe65zcdwzVL5GTsQqIvqHiY4z en+Q3ODUf4uvXCLhGBs/3X8yUpAc7GpDzU7YA= MIME-Version: 1.0 Received: by 10.223.58.8 with SMTP id e8mr7357270fah.27.1320875045409; Wed, 09 Nov 2011 13:44:05 -0800 (PST) Received: by 10.223.54.15 with HTTP; Wed, 9 Nov 2011 13:44:05 -0800 (PST) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F6025FEE@Hermes.columbia.ads.sparta.com> Date: Wed, 9 Nov 2011 16:44:05 -0500 Message-ID: From: Brian Dickson To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 21:44:28 -0000 Rather than respond, point-by-point, I will top-reply, and try to clear this up in a structured manner. First, from the perspective of normative references: - most of the main SIDR documents reference each other, both generally, and in specific places. -- e.g. -rpki-algs-05 refers to -arch, -cp, -res-certs and -signed-object -- e.g. -cp explicitly delegates algorithm specification to -rpki-algs -- e.g. -res-certs section 9, in addition to referring to -cp, clearly indicates that versions of itself and -cp need to be re-issued in lock-step -- e.g. Changing (by updating/replacing) the RFC for -rpki-algs, would actually require issuing new versions of -cp, -res-certs, and -rpki-algs, as a "document set". I believe I would be accurate in saying, one of the primary purposes of having an algorithm-agility doc, is to document what would need to happen if a new set of algorithms to be published. And the scope of the agility needs to include interaction between the RPKI system and the consumers of that data, the RPs. Let us stay with one "current" CP. Again, the presumption is: one -cp doc, one -res-certs doc, one -rpki-algs doc; and the agility doc describing the necessary state changes to go from one controlling, unified set of docs, to another controlling, unified set of docs. It's is all about the content of the "rpki-algs" document; everything (the top-down and exponential growth issues in particular) hinge on that. [terminology] Alg.suite =3D { algorithms } Let A denote Alg.Suite "A" (upper case means suite) let a denote algorithm (or alg-pair) "a" (lower case means algorithm) A example of the above would be: X =3D { n p q } [end terminology] [example cases] A =3D { a } B =3D { b } C =3D { a b } =A0 =A0(Algorithm suite C, includes algorithms "a" and "b") [end example cases] Note the following (Venn diagram) results: A ^ B =3D { } A ^ C =3D { a } =3D A C ^ B =3D { b } =3D B A v B =3D { a b } =3D C A v C =3D { a b } =3D C C v B =3D { a b } =3D C The current algorithm-agility document presumes that an algorithm update will always be of the form "A -> B". It is because of the fact that A ^ B =3D {}, that the duplicate certs problem arises, which gives rise to the exponential problem, which leads to top-down. With more than one suite, it becomes necessary to have multiple certs. A cert is only valid within one suite. If you consider suites A and C, note that a cert valid under A, is _also_ valid under C - it does not require new key date; it may need to re-issue. If, instead, the updates were done by two successive, albeit technically independent, updates, "A -> C", followed by "C -> B", the problem goes away. The timelines involved for "A -> C" would look like: =A0 Process for RPKI CAs: =A0 =A0 Phase 0 =A0 Phase 1 =A0 Phase 2 =A0 Phase 3 =A0 -----------x--------x--------x---------- =A0 =A0 ^ =A0 =A0 =A0 =A0^ =A0 =A0 =A0 =A0^ =A0 =A0 =A0 =A0^ =A0 =A0 | =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0| =A0 =A0(1) =A0 =A0 =A0(2a) =A0=A0=A0 (3) =A0 =A0 =A0(4) =A0 Process for RPKI RPs: =A0=A0=A0 Phase 0 =A0 =A0=A0 Phase 1 =A0 --------------x-----x------------------- =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 ^ =A0 =A0 | =A0 =A0 =A0 =A0 =A0 | =A0 =A0 | =A0 =A0(1) =A0 =A0 =A0 =A0 (2b)=A0 (3) =A0 (1) RPKI's algorithm document updated. =A0 (2a) CA Ready Algorithm C Date (all CAs can accept algorithms in set C, "a" or "b" specifically) =A0 (2b) RP Ready Algorithm C Date (all RPs can validate algorithms in set C, "a" or "b" specifically) =A0 (3) CA/RP Set Algorithm C Date (all RPs and CAs now are ready - on or after later of 2a/2b) =A0 (4) CA Go Algorithm C Date (any given CA can now _choose_ to switch from using "a" to using "b") The mechanics on re-issuing certificates are clear. In the last paragraph of "sidr-arch", section 4.2: If a CA certificate is reissued with the same public key, it should not be necessary to reissue (with an updated AIA URI) all certificates signed by the certificate being reissued. Therefore, a certification authority SHOULD use a persistent URI naming scheme for issued certificates. That is, reissued certificates should use the same publication point as previously issued certificates having the same subject and public key, and should overwrite such certificates. So, if we presume that Algorithm suite C allows the choice of two algorithms, then a CA can switch from one algorithm to the other by (a) re-requesting its own CA cert using the PoP of its new public key, which is the public key for algorithm "b"; and (b) reissuing all of its certificates using the new key. Every certificate is signed by exactly one algorithm, and there is no problem with the algorithm being either "a" or "b". RPs understand both "a" and "b" before this happens. There is no requirement for keeping more than one certificate, so there is no exponential problem. (Each cert identifies algs by OID.) And furthermore, the re-issuing is done unilaterally by each CA, meaning each CA can choose to do so (or not!) any time after the "go" date. This can happen at any time, in any order, independently. Note very well: The most important aspect of this is, that _each_ CA, in this model, has the ability to roll back unilaterally, since both algorithms are valid. There are no timing or hierarchy dependencies to this. In fact, the only time there is a need for ensuring all CAs have done so, is when there is a "C -> B" update. All that needs to happen for "C -> B" is for every CA to have re-issued their certs using suite B (alg "b" only), by that date, and to stop accepting requests with public keys of alg "a" at that time. Again, at no time in this transition are duplicate certs needed (neither 2 nor 3, no exponentiation). And the re-issuing is done unilaterally by each CA, with no top-down requirement. You are right on this issue: - The RPs and PoP rules definitely mean that only one rpki-algs document and one CP can be "current" (phase 0) at any time, globally. However, I disagree that that single algorithm suite, needs to contain only _one_ pair of algorithms. The wisdom of the WG, and of expert advice from the PKIX folks, should inform the contents of the rpki-algs, and conceivably this could contain more than one hash/keying algorithm pair. E.g. RSA/SHA 384 and 512, and also an EC algorithm, for a choice of 3 algs. As long as the alg choices are justified and mainstream, I don't see any problem with more than one. One other point about "C -> B" transitions: the transition avoids the top-down (or exponential) issue, if C ^ B =3D B, i.e. if C is strictly a superset of B. However, nothing in this rule places restrictions on the sizes of C or B. It is conceivable that more than one algorithm be retired during such a transition. It is also entirely possible that the post-retirement set of algorithms be larger than one. E.g C =3D { a b c d e }, B =3D { b c e }. This creates more flexibility in terms of WG work, and more perceived stability operationally. CAs are then free to choose from multiple algorithms. Thus, zero day risks on one active algorithm don't require IETF response, as CAs can trivially switch to another active algorithm. I'd even go so far as suggesting pre-publishing "document sets" (-cp, -rpki-algs, -res-certs) for multiple future alg sets, in advance, well in advance, to give implementers and operators the longest possible lead time. Respectfully, Brian P.S. The multiple CP and CPS goes away in the above - so long as the rpki-algs supports multiple algs. On Wed, Nov 9, 2011 at 1:42 PM, Stephen Kent wrote: > At 1:27 AM -0500 11/8/11, Brian Dickson wrote: > > ... > > I do not support adoption of this document in its current form. > > The main reasons have to do with fundamental aspects which at a high > > level have been addressed by my colleagues, > > so, this is a Verisign critique, provided by you, Eric, and Danny? > > Here's why: > - everybody is a CA. Both the "root" of the INR tree (ICANN/IANA), > plus the RIRs, etc., down to the publishers of EE certs. > > yes, essentially every actor in the RPKI is both a CA and an RP. > > - each CA publishes its policy via a CPS (it's a SHOULD, but > functionally a MUST for RPs to be able to understand what a CA > publishes.) > > small ISPs and orgs that have address space probably will not bother with= a > CPS, which is why it is a SHOULD, not a MUST. In a typical PKI context, a > CPS primarily benefits the subjects to whom certs are issued; RPs also ar= e > potential CPS consumers.=A0 In the RPKI, a "keaf" CA issues certs to itse= lf, > so a CPS is not of much interest for the first class of consumers. In the > RPLI one does not get to shop around to choose a CA, so RPs don't need mu= ch > from a CPS. > > > - Each CPS specifies the OID of the corresponding CP > > there is just one CP. not clear form your statement if thatr ws clear. > > - Each CP refers to the corresponding policy for algorithms > > there is only one policy (CP) for the RPKI, and it specifies algs via a > reference to an alg spec. so, I am not sure what you have in mind here. > > - Algorithms themselves have OIDs and are referenced as such in certs > > yes. > > - Every cert also specifies the OID of the CP itself (which embodies > > the rules for allowed algorithms) > > yes. > > So while the first revision of the CP insists on only one algorithm > for pub/private keys, and one algorithm for hashes, it explicitly > calls out that these are expected to change. > > yes. > > In changing allowed algorithms, it can reasonably be inferred that CPs > could be issued which increase the _number_ of allowed algoriths of > both types beyond one. > > there is only one CP. > > And similarly, the methodology demonstrated by key rollover has local > > scope. There is no requirement that children do anything at all when a > parent executes a key roll. _This is by design_. > > yes, this is by design, but is irrelevant to the the alg transition desig= n, > which has global impact (on all RPs). > > So the analogous high-level design for agility SHOULD be as follows: > - new CP documents may be published, with new OIDs > > as I mentioned above, there is one CP for the RPKI. When you suggest mult= ile > CPs, are you thinking of them on a per CA basis, or RPKI-wide? > > - ONLY when a CA with a given CPS decides to change CP does that CA > need to execute a locally-significant key+alg roll > > see question above. also, unlike key roll, an alg roll affects ALL RPs, > which is why the analogy between the two procedures is bad. Also, note my > 'reply to Brian re the top-dowen deployment model that the Wg adopted, to > avoid > exponential growth in the repository system. > > - The CA would issue new certs with the new CP which itself lists > > additional algorithms > > ibid. > > - The same procedure would be executed in multiple phases - issue new > child certs published under the old main cert; move them to the new > cert, rewriting/overwriting in the same location > > ibid. > > This could be handled gracefully by having two CPs - one CP having the > additional algorithm(s), and subsequently another CP with the new but > > minus the old. > > not graceful re repository growth, and impact on RPs. > > This mechanism could be used to introduce new algorithms without > requiring retiring specific old algorithms. The two actions - adding > and removing - are in fact independent, beyond the requirement that > there be at least one algorithm (which goes without saying, really). > The only other requirement is that the issued certs have algorithms > consistent with the specified CP (OID) attached to the cert. > > there needs to be one alg that ALL RPs can deal with at all times.=A0 Als= o, > unlike key roll, when a CA wants to have a new cert with a public key > using a new alg, its parent MUST be able to support that alg, because of > the PoP requirement. > > I may be completely off the mark, but this would seem to be much more > in line with the whole manner in which algorithms, policies, resource > objects, etc., have been separated out and linked by normative > reference. > > I do not agree. > > Perhaps we could get Geoff Huston to comment on my interpretation of > the CP/CPS/alg interaction and explicit/implicit rules? > Is it intended that CAs have a uniform hierarchy using exactly one > algorithm set, or is it intended that each CA be able to specify (via > > CPS + CP)=A0 the set of algorithms it supports, with the initial CP > document being the minimum acceptable algorithm set? > > This text suggests that you believe there is on CP per CA, vs. a > system-wide CP. The architecture is the latter.=A0 Also, while I respect > Goeff, why is your question directed to him? I am a co-author of the CP, > the arch, and the key roll and the alg roll docs :-). > Steve From kent@bbn.com Wed Nov 9 13:51:09 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D077311E80B0 for ; Wed, 9 Nov 2011 13:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.452 X-Spam-Level: X-Spam-Status: No, score=-106.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-s-m+ptghcy for ; Wed, 9 Nov 2011 13:51:09 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 52B1411E8080 for ; Wed, 9 Nov 2011 13:51:09 -0800 (PST) Received: from dhcp89-089-006.bbn.com ([128.89.89.6]:49163) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1ROG2d-0006io-RV; Wed, 09 Nov 2011 16:50:45 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <60C11709-5D46-474A-A4DB-ADE0675E73D8@apnic.net> References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> <10A3F6FD-1392-4E6E-A048-A8EED1E8C329@apnic.net> <60C11709-5D46-474A-A4DB-ADE0675E73D8@apnic.net> Date: Wed, 9 Nov 2011 15:18:19 -0500 To: Geoff Huston From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr wg list Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 21:51:09 -0000 At 6:56 AM +1100 11/10/11, Geoff Huston wrote: >... >I did not claim it existed - I merely disagreed with the claim of its >impossibility of existence. OK. >In the same way that the only way you can eliminate the "unknown" validation >outcome is to achieve universal adoption of the generation of credentials, >the general visibility of intent relies on universal adoption on the >generation >of routing policy. It is not impossible per se, it just relies on >universal adoption! agreed. >In the case of the efforts relating to RPSL, reality has not >achieved such targets >of universal adoption, as you point out. OK. >In the case of the efforts relating to the BGP security mechanisms >you are working >on, it is an open issue as to how many folk would adopt it, but our >experiences >of other technologies, including 4 byte ASN support indicate that universal >adoption is an extremely challenging objective. no argument. Thanks for the thoughtful, detailed reply. Steve From kent@bbn.com Wed Nov 9 13:51:23 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782DA11E8085 for ; Wed, 9 Nov 2011 13:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.46 X-Spam-Level: X-Spam-Status: No, score=-106.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSIkTUW184Fj for ; Wed, 9 Nov 2011 13:51:22 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id CE15A11E809A for ; Wed, 9 Nov 2011 13:51:22 -0800 (PST) Received: from dhcp89-089-006.bbn.com ([128.89.89.6]:49163) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1ROG2d-0006io-8t; Wed, 09 Nov 2011 16:50:43 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F6025FEE@Hermes.columbia.ads.sparta.com> Date: Wed, 9 Nov 2011 16:50:24 -0500 To: Brian Dickson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 21:51:23 -0000 At 7:48 AM -0500 11/8/11, Brian Dickson wrote: >... >What I am saying is, there is no reason to require a change to a child's CPS, >and thus its CP, and thus its algorithm suite, simply because the parent CA >is making this change. The whole 'all (non-leaf)' stuff is un-necessary. this text makes it sound as though there is a per CA CP. The CP for the RPKI is global. One possibility is that the CP is updated to refer to two alg suites, and two policy OIDs, supplanting the old CP. Since the changes would be limited to a vert small part of the CP, it is not clear that one would want to have multiple CPs in place for the RPKI at the same time. Also, removing the alg description from the CP was intended to make the change to a new alg suite more modular. Still, the difference between two CPs or one is not so critical to this discussion. >Each CA may operate its CPS independently. Algorithms are explicitly included >via OIDs in every cert. A child CA may need to sign with algorithms >accepted by >the parent CA, but they can issue certs with a different CP, signed according >to the algorithms _of_that_CP_ (their own CP, independent of the choice of >CP used by the parent CA). Every CA nominally has a CPS, so part of the statement above is confusing. There are limitations to what a CA can do vs. what algs its parent supports, e.g., because of PoP. >The choice of algorithm acceptability for a given cert, comes from the CP. >It needs internal consistency. There is no further requirement on >algorithm choice. not entirely true. each CA MUST perform PoP (3.2.1 of the CP) when issuing a cert to a subordinate CA. To perform PoP, the issuer must be prepared to deal with the alg in the subordinate CA's public key info. > > The process that you have described is indeed the proposed algorithm in the >> document for the CAs, where we adopted a "top-down" process and we maintain >> the two suites independent. The document also includes the transition to the >> new suite on the RPs that are distributed globally. > >That's the part I disagree with entirely - there is no "top-down" >required at all. >There is no "globally". There is only the requirement operationally >that any newly >published CP with new OID be supported by RPs. Top down is strongly motivated because of the PoP issue, and because of the repository growth issue. the WG agreed to mandate top down alg transition last year (July, 2010), after a briefing at IETF 78. See the proceedings for details. >The publishing the new CP with new OIDs with sufficient time for RPs >to implement >those changes is the only timeline issue. It is a "sunrise" issue - a >minimum time >after publication before ANY CA begins to issue certs using the new OID. > >After that date, any CA may choose to use the new CP, without >requiring any change >to either the CA's parent, or the CA's children, except as relates to >the algorithms >used on new certs, which the child needs to discover. This has no >bearing on the >CP _used_ by the child CA in issuing certs to grand-child CAs - that >is under the >local policy of the child CA. > >Every CA is free to choose the CP it uses from among the published CPs, modulo >the issue date plus delay required (6 months in the initial CP document). > >Issuing a second (or third, or fourth) CP does _not_require_ANY_ CA to change >algorithm suite. > >Perhaps a separate BCP can recommend, or even require, use of some subset >of CP documents, or at some point an old CP could be moved to historic or >depracated status. The very brief description provided above does not contain sufficient detail to enable it to be compared to the current proposal. it also fails to address issues such as PoP, repository growth, and the burden imposed on CAs and RPs to support algs forever, if some small set of CAs or RPs choose to not transition. >However, that should _not_ be part of the alg-agility document. >Agility should limit >itself to the mechanism by which a _single_ CA changes algorithm >suite, including >the possibility that the new suite still include all the algorithm(s) >from the previous >suite, the possibility that multiple algorithms are part of the new >suite, as well as >case of (but not a requirement that) _an_ older algorithm is dropped >from the suite. We do not believe that alg suite changes are unilateral decisions by CAs, for the various reasons cited above. Steve From jakob.heitz@ericsson.com Wed Nov 9 14:11:10 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD00321F84A2 for ; Wed, 9 Nov 2011 14:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.147 X-Spam-Level: X-Spam-Status: No, score=-6.147 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYQxBJTrHPUD for ; Wed, 9 Nov 2011 14:11:10 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id CE40B21F84A1 for ; Wed, 9 Nov 2011 14:11:09 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pA9MAm8J006410; Wed, 9 Nov 2011 16:11:09 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.52]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 9 Nov 2011 17:11:01 -0500 From: Jakob Heitz To: Eric Osterweil , "Sriram, Kotikalapudi" Date: Wed, 9 Nov 2011 17:11:00 -0500 Thread-Topic: Beacons in a separate TCP Thread-Index: AcyfLDg0j50Bi0neROCKFI3By4evPA== Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A44963DA0@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: [sidr] Beacons in a separate TCP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 22:11:11 -0000 The beacons will be unlikely to come like the slow constant drizzle of Seattle weather, but more like the quick cloudbursts of Miami weather. Just guessing. Such beacons will cause head-of-line blocking for more urgent updates behind them. Beacons can be delayed for hours without consequence. Not so for other updates. I think beacons should be transmitted in a TCP session separate from the normal BGP traffic, so as not to delay that. -- Jakob Heitz. > -----Original Message----- > From: Eric Osterweil [mailto:eosterweil@verisign.com] > Sent: Wednesday, November 09, 2011 12:37 PM > To: Sriram, Kotikalapudi > Cc: Jakob Heitz; sidr wg list > Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs >=20 > Hey Sriram, Russ, and Jakob, >=20 > Thanks for the #s. I think I get the general notion that adding n > updates per day per prefix equals (n * #prefixes)/1. :) I guess my > question was kinda vague, sorry. Upon reexamination, I see that I > said "overhead" without being specific. Since we can use the > updates that are generated today to measure how much (for example) > bandwidth is already needed, can we calculate how much extra > bandwidth universal deployment would mean? Also, perhaps this would > be most informative in the form of a ratio (i.e. a factor of $x$ > increase). That way, when people look at events like the one that > the "General Internet Instability" thread that just happened on > NANOG refer to, they can gauge the update amplification that was > seen against what _would_ be seen given bgpsec. I think this > actually kind of came up on nanog, so it seems like maybe it would > be a relevant thing to look at here? >=20 > Anyway, I guess I was mostly just curious about what kinds of > evaluations have been done, thanks. :) >=20 > Eric >=20 > On Nov 8, 2011, at 12:19 PM, Sriram, Kotikalapudi wrote: >=20 > > Now the ops doc has much longer beaconing interval recommendations > for > > what you may consider a normal prefix. > > > > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-01#section-7 > > > > Normal Prefix: Most prefixes SHOULD announce with a > signature > > validity of a week and beacon every three days. > > > > Sriram > > > > -----Original Message----- > > From: Jakob Heitz [mailto:jakob.heitz@ericsson.com] > > Sent: Tuesday, November 08, 2011 12:09 PM > > To: Sriram, Kotikalapudi > > Cc: Christopher Morrow; Eric Osterweil; sidr wg list > > Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs > > > > Proposal was 24 hour beacon timeout and 3 beacons per timeout. > That makes 3 beacons per day. > > > > -- > > Jakob Heitz. > > > > From kent@bbn.com Wed Nov 9 14:21:48 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3334B21F8496 for ; Wed, 9 Nov 2011 14:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.468 X-Spam-Level: X-Spam-Status: No, score=-106.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwvV3IF7njjn for ; Wed, 9 Nov 2011 14:21:47 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A414221F8476 for ; Wed, 9 Nov 2011 14:21:47 -0800 (PST) Received: from dhcp89-089-006.bbn.com ([128.89.89.6]:49163) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1ROG2f-0006io-Nw; Wed, 09 Nov 2011 16:50:45 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F6025FEE@Hermes.columbia.ads.sparta.com> Date: Wed, 9 Nov 2011 16:28:04 -0500 To: Brian Dickson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 22:21:48 -0000 Brian, ... When three individuals from the same organization begin to comment on a WG document during last call, and two of the individuals have no history of substantial participation in the WG, one begins to question whether this is mere coincidence. Your reference to "colleagues" struck me as odd (based on 25 years of reading and posting messages on IET WG lists), if you didn't mean to refer to Eric and Denny. ... >I'll address the content-oriented portion of your email in a separate message. > >Brian >- not using any email-address that would suggest affiliation - Using an address that obscures ones organizational affiliation has the potential to raise questions rather than deflect them. Steve From danny@tcb.net Wed Nov 9 18:43:05 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447D521F85EF for ; Wed, 9 Nov 2011 18:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ws3uIIuBIMKE for ; Wed, 9 Nov 2011 18:43:04 -0800 (PST) Received: from uu.ops-netman.net (morrowc-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:36e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 83EB021F85B8 for ; Wed, 9 Nov 2011 18:43:04 -0800 (PST) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [208.76.12.119]) by uu.ops-netman.net (Postfix) with ESMTP id 2D38F1900A8; Thu, 10 Nov 2011 02:43:01 +0000 (UTC) Received: from dul1dmcphers-m1.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (Authenticated sender: danny@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 15372320093; Thu, 10 Nov 2011 02:43:00 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4--1011603339 From: Danny McPherson In-Reply-To: Date: Wed, 9 Nov 2011 21:43:00 -0500 Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F6025FEE@Hermes.columbia.ads.sparta.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 02:43:05 -0000 --Apple-Mail-4--1011603339 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 9, 2011, at 1:42 PM, Stephen Kent wrote: >>=20 >> The main reasons have to do with fundamental aspects which at a high >> level have been addressed by my colleagues, >=20 > so, this is a Verisign critique, provided by you, Eric, and Danny? Steve,=20 Not that I need to justify or explain this to you or anyone else here... = I agree it is quite interesting that we all arrived at similar conclusions = with=20 NO express coordination on this end - perhaps it's indicative of finally giving due consideration to what operationalizing and being held captive=20= to such things entails - not simply 'running code, [standards], and run=20= away', having to operationalize certainly impacts perspective. The purpose of last call is to encourage folks to review the documents,=20= I'd have thought you would welcome such reviews, unless the goal is=20 for "the authors" to simply prescribe to the working group and use SIDR=20= as a publication medium for work done outside the IETF. Furthermore,=20 given the barrage of documents that will eventually lead to operational=20= requirements for some folks involved in these efforts, I'm very = concerned=20 they'll not get proper review. BTW: if you'd really like to evaluate contributions and funding sources in full let me know, I'm sure I can plot some dependency graphs for you = ;-) I'll say no more on this topic here and stand by the technical merit of=20= comments made -- if ANYONE would like more details on any of this=20 find me in TPE. -danny --Apple-Mail-4--1011603339 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The main reasons have to do with = fundamental aspects which at a high
 have been = addressed by my colleagues,

so, this = is a Verisign critique, provided by you, Eric, and = Danny?

Steve, 
Not that I need to justify or explain this to you or anyone = else here...  I
agree it is quite interesting that we all = arrived at similar conclusions with 
NO express = coordination on this end - perhaps it's indicative = of finally
giving due consideration to what = operationalizing and being held captive 
to such = things entails - not simply 'running code, [standards], and = run 
away', having to operationalize certainly impacts = perspective.

The purpose of last call is to = encourage folks to review the documents, 
I'd have = thought you would welcome such reviews, unless the goal = is 
for "the authors" to simply prescribe to the working = group and use SIDR 
as a publication medium for work done = outside the IETF.  Furthermore, 
given the barrage = of documents that will eventually lead to = operational 
requirements for some folks involved in = these efforts, I'm very concerned 
they'll not get proper = review.

BTW: if you'd really like to evaluate = contributions and funding sources
in full let me know, I'm = sure I can plot some dependency graphs for you = ;-)

I'll say no more on this topic here and = stand by the technical merit of 
comments made -- if = ANYONE would like more details on any of this 
find me in = TPE.

-danny


= --Apple-Mail-4--1011603339-- From danny@tcb.net Wed Nov 9 18:56:20 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA6F21F86F6 for ; Wed, 9 Nov 2011 18:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqelmIbiGEai for ; Wed, 9 Nov 2011 18:56:19 -0800 (PST) Received: from uu.ops-netman.net (morrowc-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:36e::2]) by ietfa.amsl.com (Postfix) with ESMTP id B3DA721F86EE for ; Wed, 9 Nov 2011 18:56:19 -0800 (PST) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [208.76.12.119]) by uu.ops-netman.net (Postfix) with ESMTP id 57F9F1900D2 for ; Thu, 10 Nov 2011 02:56:19 +0000 (UTC) Received: from dul1dmcphers-m1.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (Authenticated sender: danny@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 547FE32017A for ; Thu, 10 Nov 2011 02:56:18 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Danny McPherson In-Reply-To: <60C11709-5D46-474A-A4DB-ADE0675E73D8@apnic.net> Date: Wed, 9 Nov 2011 21:56:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <32744.216.168.239.87.1320175657.squirrel@webmail.tcb.net> <080F8FFF-D2C7-4414-B53A-233F88D2009F@vpnc.org> <53FA9B4A-552C-4998-8F69-592A0F5AA13B@verisign.com> <10A3F6FD-1392-4E6E-A048-A8EED1E8C329@apnic.net> <60C11709-5D46-474A-A4DB-ADE0675E73D8@apnic.net> To: sidr wg list X-Mailer: Apple Mail (2.1084) Subject: Re: [sidr] BGPSEC Threat Model ID X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 02:56:20 -0000 On Nov 9, 2011, at 2:56 PM, Geoff Huston wrote: >=20 > I did not claim it existed - I merely disagreed with the claim of its=20= > impossibility of existence. >=20 > In the same way that the only way you can eliminate the "unknown" = validation > outcome is to achieve universal adoption of the generation of = credentials, > the general visibility of intent relies on universal adoption on the = generation > of routing policy. It is not impossible per se, it just relies on = universal adoption! >=20 > In the case of the efforts relating to RPSL, reality has not achieved = such targets > of universal adoption, as you point out. >=20 > In the case of the efforts relating to the BGP security mechanisms you = are working > on, it is an open issue as to how many folk would adopt it, but our = experiences > of other technologies, including 4 byte ASN support indicate that = universal > adoption is an extremely challenging objective. I completely agree with you here Geoff - and a resource certification=20 infrastructure to bootstrap IRRs, coupled with a few lessons learned=20 from the RIPE playbook and beyond, and their potential utility is orders=20= of magnitude beyond where it currently is and addresses that residual=20 risk (my primary concern) that current solutions fail to address. -danny=20= From danny@tcb.net Wed Nov 9 19:01:27 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F8221F8437 for ; Wed, 9 Nov 2011 19:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWNJl5d7yixi for ; Wed, 9 Nov 2011 19:01:26 -0800 (PST) Received: from uu.ops-netman.net (morrowc-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:36e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 080AA11E8086 for ; Wed, 9 Nov 2011 19:01:24 -0800 (PST) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [208.76.12.119]) by uu.ops-netman.net (Postfix) with ESMTP id 020A61900AC; Thu, 10 Nov 2011 03:01:22 +0000 (UTC) Received: from dul1dmcphers-m1.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (Authenticated sender: danny@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id BF4BD320283; Thu, 10 Nov 2011 03:01:21 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-6--1010501608 From: Danny McPherson In-Reply-To: Date: Wed, 9 Nov 2011 22:01:21 -0500 Message-Id: References: To: Samuel Weiler X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 03:01:27 -0000 --Apple-Mail-6--1010501608 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 8, 2011, at 2:49 PM, Samuel Weiler wrote: > This document is basically ready for publication. While it is > painfully long, it is arguably one of the better written documents > this WG has produced. My thanks to the editors for their efforts. Sam,=20 So am I crazy for thinking that putting all this effort in place and = then simply saying "just use expired certificates, even after rollovers, and even = from the=20 algorithm that you just rolled over from, and even though they may have=20= previously been in CRLs but aren't now because they're expired" is even=20= remotely acceptable? I don't see how we can publish this until that issue is resolved. -danny --Apple-Mail-6--1010501608 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
This document = is basically ready for publication.  While it is
painfully long, = it is arguably one of the better written documents
this WG has = produced.  My thanks to the editors for their = efforts.

Sam, 
= So am I crazy for thinking that putting all this effort in place and = then simply
saying "just use expired certificates, even after = rollovers, and even from the 
algorithm that you just = rolled over from, and even though they may = have 
previously been in CRLs but aren't now because = they're expired" is even 
remotely = acceptable?

I don't see how we can publish this = until that issue is = resolved.

-danny

= --Apple-Mail-6--1010501608-- From danny@tcb.net Wed Nov 9 19:25:33 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E6D11E8088 for ; Wed, 9 Nov 2011 19:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.332 X-Spam-Level: X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwyCgBfyETHa for ; Wed, 9 Nov 2011 19:25:32 -0800 (PST) Received: from uu.ops-netman.net (morrowc-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:36e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2415F11E8081 for ; Wed, 9 Nov 2011 19:25:32 -0800 (PST) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [208.76.12.119]) by uu.ops-netman.net (Postfix) with ESMTP id C81461901D6; Thu, 10 Nov 2011 03:25:31 +0000 (UTC) Received: from dul1dmcphers-m1.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (Authenticated sender: danny@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 9E1DF3202EF; Thu, 10 Nov 2011 03:25:26 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-13--1009143487 From: Danny McPherson In-Reply-To: Date: Wed, 9 Nov 2011 22:24:00 -0500 Message-Id: <72225729-ECBE-48AE-BEC7-EC3C0EF63974@tcb.net> References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com>, To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 03:25:33 -0000 --Apple-Mail-13--1009143487 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 8, 2011, at 7:59 AM, Sriram, Kotikalapudi wrote: > According to=20 > http://bgpupdates.potaroo.net/instability/bgpupd.html=20 Sriram,=20 To quote from the page you reference: "The data has been gathered using a single eBGP peering with AS 131072." We've got over 450 peers with multiple interconnects in 70+ locations, = with=20 many prefixes asserting reachability from multiple eBGP paths, and = *millions*=20 of eBGP-learned paths on many routers today -- and we're not even an = ISP. Unless I'm missing something, I think this has some material impact on = your=20 numbers... -danny > the current global BGP system produces > Average Prefixes per BGP Update: 2.24 > Average BGP Update Messages per second: 1.13 =09 > Average Prefix Updates per second: 2.53 > =46rom this we can compute: > Average Prefix Updates per day =3D 218696 >=20 > Now if we consider a BGPSEC island of 100,000 participating prefixes > (multiple ISPs form a BGPSEC island and there is BGPSEC between > them and also in each ISP's entire customer cone): > With 24 hour beaconing interval, we would have: > Prefix Updates per Day =3D 100,000 (seen at each BGPSEC router) > BGPSEC Update Size =3D 420B (for ECDSA-256) > Average Bandwidth Required =3D 3.89 kbps (averaged over a day)=20 >=20 > Does this answer what you were asking for? >=20 > Sriram=20 >=20 >=20 >=20 > _______________________________________________ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-13--1009143487 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


Sriram, To quote from the page you reference:

"The = data has been gathered using a single eBGP peering with AS = 131072."

We've got over 450 peers with = multiple interconnects in 70+ locations, = with 
many prefixes asserting reachability from = multiple eBGP paths, and *millions* 
of = eBGP-learned paths on many routers today -- and we're not even an = ISP.

Unless I'm missing something, I think this = has some material impact on = your 
numbers...

-danny
=
the current global BGP = system produces
Average Prefixes per BGP Update: = 2.24
Average BGP Update Messages per second: 1.13 = =
Average Prefix Updates per second: = 2.53
=46rom this we can compute:
Average Prefix Updates per = day =3D = 218696

Now if we consider a BGPSEC island of 100,000 = participating prefixes
(multiple ISPs form a BGPSEC island and there = is BGPSEC between
them and also in each ISP's entire customer = cone):
With 24 hour beaconing interval, we would have:
Prefix = Updates per Day =3D 100,000 (seen at each BGPSEC router)
BGPSEC = Update Size =3D 420B (for ECDSA-256)
Average Bandwidth Required =3D = 3.89 kbps (averaged over a day)

Does this answer what you were = asking for?

Sriram =



_______________________________________________

___= ____________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/ma= ilman/listinfo/sidr

= --Apple-Mail-13--1009143487-- From danny@tcb.net Wed Nov 9 19:25:33 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBB611E8081 for ; Wed, 9 Nov 2011 19:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.334 X-Spam-Level: X-Spam-Status: No, score=-102.334 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ec42orxJgjB for ; Wed, 9 Nov 2011 19:25:32 -0800 (PST) Received: from uu.ops-netman.net (morrowc-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:36e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3694311E8086 for ; Wed, 9 Nov 2011 19:25:32 -0800 (PST) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [208.76.12.119]) by uu.ops-netman.net (Postfix) with ESMTP id C80FC1901D5; Thu, 10 Nov 2011 03:25:31 +0000 (UTC) Received: from dul1dmcphers-m1.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (Authenticated sender: danny@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id D6C04320319; Thu, 10 Nov 2011 03:25:27 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2--1009055232 From: Danny McPherson In-Reply-To: Date: Wed, 9 Nov 2011 22:25:28 -0500 Message-Id: <30BC761A-67AB-4E08-9BC1-0B2E204AD7DE@tcb.net> References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com> <92AA1C8B-7CDB-406E-AA83-7C1BCD83CB69@ericsson.com> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 03:25:33 -0000 --Apple-Mail-2--1009055232 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Nov 8, 2011, at 12:19 PM, Sriram, Kotikalapudi wrote: > Now the ops doc has much longer beaconing interval recommendations > for what you may consider a normal prefix. > > http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-01#section-7 > > Normal Prefix: Most prefixes SHOULD announce with a signature > validity of a week and beacon every three days. Seriously? After all this effort exposure window of 72 hours or more now - I can do far better than this manually in meatspace. Where are these numbers coming from? It's interesting the onus is on the sender to set the periodic update rates, yet the load is on every other participant in the system. We've seen how well this works in practice. -danny --Apple-Mail-2--1009055232 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Now the ops = doc has much longer beaconing interval recommendations
for what you = may consider a normal prefix.

http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-01#section-7
= Normal Prefix:  Most prefixes SHOULD announce with a = signature
In-Reply-To: <7041B49A-6675-4010-B506-435AE2B7BF4C@tcb.net> Date: Thu, 10 Nov 2011 11:09:49 +0100 Message-Id: References: <7041B49A-6675-4010-B506-435AE2B7BF4C@tcb.net> To: Danny McPherson X-Mailer: Apple Mail (2.1084) Cc: Sandra Murphy , sidr wg list Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 10:10:29 -0000 --Apple-Mail-75--984785135 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Danny, Thank you for your comments and please see the response to your = comments. Sorry for the delay. Roque. >=20 > On Oct 20, 2011, at 10:50 AM, Sandra Murphy wrote: >=20 >> The authors have requested a WG LC for draft "Algorithm Agility = Procedure for RPKI." >>=20 >> The document and the draft version history are available at >> http://tools.ietf.org/html/draft-ietf-sidr-algorithm-agility-03 >>=20 >> The last call will end Thu, 3 Nov 2011 (AOE). >=20 >=20 > --------------------------------------- > Substantial; >=20 > --- > In S 4.6 (Phase 3) you state that all signed product sets are = available > using both algorithms and all RPs MUST be able to validate using = either=20 > suite. Further, you state that an object that validates using either=20= > Algorithm Suite A or Algorithm Suite B MUST be considered valid,=20 > but in the subsequent sentence it is "RECOMMENDED" that RPs utilize > only Suite B for validation [throughout Phase 3]. =20 >=20 > Is the recommendation you're making that if product sets are available=20= > via both Algorithm Suite A and Algorithm Suite B then the Suite A = product > sets SHOULD NOT be validated by RPs in order to minimize processing=20 > overhead and the probability of cryptographic vulnerabilities = resulting > in downgrade attacks?=20 >=20 > Or SHOULD NOT be validated by RPs unless Algorithm Suite B validation=20= > failure occurs, then fallback to the Algorithm Suite A product set =20 > should be considered? Or something else? S.6 guidelines provide "As=20= > a general rule, the validation of signed objects using different=20 > algorithm suites are independent and the RP MUST NOT keep any=20 > relationship between the different hierarchies", which seems to be=20 > in conflict with the recommendation above unless some implementation=20= > optimization or minimization of vulnerability to downgrade attacks=20 > is being contemplated? The intention was to let the RP to try to use Alg B first to facilitate = the transition. I agree with your that the text was not clear. What about this new text for section 4.6? "Phase 3 starts at the RP Ready Algorithm B Date. During this phase, = all signed product sets are available using both algorithm suites and = all RPs MUST be able to validate them using either suite. An object = that validates using either Algorithm Suite A or Algorithm Suite B MUST = be considered valid. It is RECOMMENDED that, in preparation for Phase 4, = RPs utilize Suite B as the first and preferred option for validation = throughout this phase. Thus, for example, an RP SHOULD try to validate = the sets of signed products retrieved from the Algorithm Suite B = repository first.=20 If this effort fails (relative to the local validation policy), the RP = SHOULD revert to using the Algorithm Suite A repository." For your second comment, it is clear that the RPKI system will be = vulnerable to downgrade attacks until the process is completed (EOL = date). I believe this is captured somehow in the Security Considerations = section when it says: "The procedure described in this document will = take months or years to complete an algorithm transition. During that = time, the RPKI system will be vulnerable to any cryptographic weakness = that may have triggered this procedure.". We can add some specific text: "During that time, the RPKI system will be vulnerable to any = cryptographic weakness that may have triggered this procedure (i.e. = downgrade attack)." >=20 > --- > Whatever the recommended behavior, how would it also change in Phase 4 > (Twilight), where a RP MAY continue to validate signed product sets > using Suite C (old)? If there's a failure in validation of the=20 > current algorithm then should it use the "old" objects? You seem to=20= > suggest in S.6 that this is fine, but not in S.4.7? >=20 (Roque) Would a simple reference to section 6 make the trick? > I think some more explicit guidelines about what to do and what not=20 > to do would be useful in both Phase 3 and Phase 4 behavior that aligns > with S.6 and clarifies the above issues would be of benefit. (Roque) Again, I can add a reference to S.6. > --- > Also, in S.6 it's not clear to me what you mean by "instance of a=20 > product" and "instances of such products", did you mean "signed=20 > product sets" or something else? If the former, which I think you=20 > did, then it would be really useful if this "MUST contain the same > resources" was provided much earlier in the document.=20 >=20 > "A failure to validate one instance of a product, under either=20 > algorithm Suite MUST NOT cause the RP to reject the other instance=20 > of the product. Because both instances of such products MUST contain=20= > the same resources, relying on either instance will yield the same > outcome." (Roque) I am fine on adding this text. >=20 > Whereas in Phase 4 both may not even exist, correct? =20 (Roque) Correct but also in Phase 1 and of course Phase 0. > --- > And given the above, if they "MUST contain the same resource", yet=20 > S.7 says revocations are handled independently (even though during=20 > phase 2 and phase 3 the "two certificate hierarchies are designed to=20= > carry identical information" -- what does this mean?), how do you \ > accomplish all of this in practice? (Roque) As there are independent hierarchies, you handle independent = CRLs for each CA. Unfortunately, CA software will have to handle this = "pain". > --- > Perhaps it should be that if two hierarchies exist they should be=20 > identical - however, this diverges from the guidance that algorithm > suites must be independent and the RPs MUST NOT keep any relationship > between the different hierarchies. This applies to "fallback"=20 > implementation behaviors as well, I guess... (Roque) No "fallback" is specified.=20 >=20 > Also, general guidance that as long as "old" or Algorithm Suite C=20 > data is considered in parallel to or IF "current" algorithm fails,=20 > the cryptographic vulnerabilities that triggered the rollover in the=20= > first place may well result in downgrade attacks. >=20 (Roque) Again, you are vulnerable until EOL and we can be more precise = in the text in the Security Section as referred before. > --------------------------------------- > Minor nits: (Roque) Thanks, all corrected for next version Thanks again for your review. Roque >=20 > --- > S 3 Terminology=20 >=20 > - > s/conventions use din examples/conventions used in examples/ >=20 > - > Two occurrences of this ("CA Y" & "CA Z"): >=20 > s/used in examples this document/used in examples in this document/ >=20 >=20 > --- > S 4.2 Process Overview >=20 > - > s/prohibit a CA issuing/prohibit a CA from issuing/ >=20 >=20 > --- > S 4.7 Phase 4 >=20 > s/figure describe a possible/figure describes a possible/ >=20 > --- > S 5 >=20 > s/implementing a different resource classes/implementing different = resource classes/ >=20 >=20 > --- > S 11 >=20 > s/set will not longer be valid/set will no longer be valid/ >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-75--984785135 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEFyqcUyRFrhvN5s0SHw/EO4wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA1MTAwMDAwMDBaFw0x MjA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxIp28SUiJ/fiFYD/Nct8MUbG WJuPqSnhkfBYMFbbWfDDrHR8OXzK2LkWIuHY5aeAo1nalAQCO40oeTYt0cp9W++a7USNCEDQzgVN Rg0YMYL27YSQoVJnecO3u9wi0jjwhJGblWWxphaztdaMbqiChgND1PHqf7dcs4UjeUOhhKFk0/61 mTmduV721jrxj6ABIlUHAc7nXhKANtDbKdBZzEhM4dbzp6STKq65EQ3xRLVFIuapTgNVckvXtc1e Cyu4xLOLZgaD2aLq9JzBn9y/rFRMtf2euP/Nmzl7QRjAUjpPdo1n6NXWGDtNyR0lUrcJ/x1leccZ Gfj0eaqe+tpJmQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAsvqKrlga/tU0vyBtnBOj 4miDAZxou0/fN2wVEK7dRLzIQLYEJD35sELVhiP8v8wVHtgOeVHz9FyBEVqXmJ0RKy4kMC7gdQxj +t1MlqSTDShEaPMmiwaK6M1iJ9jpBL4JvoiirpHnQYGukkgvTUeqITWZ5ecg03nB3QHuab91Gc+n RZ1OKL4D4p5IkvzWhRlIAlxW9yGZyB8r9V6iu3+1SYEpPPUN3AYCxXeXrn8fJjkOoEodybRiGyfW pMpShpTZg2tHB7ZX162Ti3sRvwA2mktDMnBtEm1pXo15z7yieDUPmjVybMA4byV7AQcbIrjQj0eq c/biBsueC2KWoJY7TDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRIfD8Q7jAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEx MTAxMDA5NThaMCMGCSqGSIb3DQEJBDEWBBQcolchROm+LmoEZw2gbAHV1x8BCTCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQDEhx1DgluP8RmJCql3tiLqDHsriA937CZvnCR5WqHkhfWw lk+BJucrsGjals5btjbD2t464PAMlYXvHCVPXeDiIxz6VkNq+TNznTI2/OGGU5RSshxyCJ5ESruW o7RZ/m9nZ2VaXHAo3zXq83YYyk5E58SKrotY9DYuUFJx74offf04iFvBhLwiAQ/u/Uf8TuOb5Cby PiSJaefgIB5V6qxMWOqomruxgGfF7zf711BUlKweCfY3zXPwoG9Oq0g0m/+i5LPuuYjUtWhkizuS 3f5bGTGTk90a96VDx3rijtKqbbR5IJR4UtEiNiSQPOWY5/2ZNR1/rYW3MoacOFCDFMvuAAAAAAAA --Apple-Mail-75--984785135-- From eosterweil@verisign.com Thu Nov 10 08:18:34 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E4121F8ACE for ; Thu, 10 Nov 2011 08:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtH5rhMPUo4h for ; Thu, 10 Nov 2011 08:18:33 -0800 (PST) Received: from exprod6og114.obsmtp.com (exprod6og114.obsmtp.com [64.18.1.33]) by ietfa.amsl.com (Postfix) with ESMTP id 69AFE21F8ABE for ; Thu, 10 Nov 2011 08:18:33 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKTrv5KQL1g4RoTFkIvuSIEwj0gyax6QV1@postini.com; Thu, 10 Nov 2011 08:18:33 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id pAAGHilA028379; Thu, 10 Nov 2011 11:17:45 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.131.30.124]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 11:17:44 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Thu, 10 Nov 2011 11:17:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4B169301-A7C5-4C1D-B470-930DB7FBDEFF@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6025FEE@Hermes.columbia.ads.sparta.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 10 Nov 2011 16:17:44.0324 (UTC) FILETIME=[4729F440:01CC9FC4] Cc: "sidr@ietf.org list" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 16:18:34 -0000 On Nov 9, 2011, at 1:42 PM, Stephen Kent wrote: > At 1:27 AM -0500 11/8/11, Brian Dickson wrote: >> ... >=20 >> I do not support adoption of this document in its current form. >>=20 >> The main reasons have to do with fundamental aspects which at a high >> level have been addressed by my colleagues, >=20 > so, this is a Verisign critique, provided by you, Eric, and Danny? Steve, This is a ridiculous question, and the implication is a completely false = characterization of my involvement. For the record: I am participating = as an individual only. Eric= From christopher.morrow@gmail.com Thu Nov 10 10:41:35 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4824A21F84A7 for ; Thu, 10 Nov 2011 10:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.426 X-Spam-Level: X-Spam-Status: No, score=-103.426 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPJON2vejGOR for ; Thu, 10 Nov 2011 10:41:34 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id AFEBC21F8483 for ; Thu, 10 Nov 2011 10:41:34 -0800 (PST) Received: by iaeo4 with SMTP id o4so4218109iae.31 for ; Thu, 10 Nov 2011 10:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UxmaiiXNEY/nloKH2pBWD8yD3P1UL6kHqjuMm4od+Tw=; b=Vi5G+rOk2t/ond6RCi3xTCDtX4FYGeDgv0t/0rjqWJX3LFJ46Q2T7gIbPTHB3X+i24 V1F516An3Mcol6pBhxr4jBz8cYiViyeERYQ6jZWMdr/MtZ+pHXZE0+UXliRIgCI+M6hq Nn5xH6BZ8Xf1CeZUV2/EA7Q/g4LdWrUOBxr5o= MIME-Version: 1.0 Received: by 10.50.36.161 with SMTP id r1mr9313235igj.37.1320950494387; Thu, 10 Nov 2011 10:41:34 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Thu, 10 Nov 2011 10:41:34 -0800 (PST) In-Reply-To: <32DF728C-A96A-435D-A54E-7626C2577F04@verisign.com> References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com> <92AA1C8B-7CDB-406E-AA83-7C1BCD83CB69@ericsson.com> <32DF728C-A96A-435D-A54E-7626C2577F04@verisign.com> Date: Thu, 10 Nov 2011 13:41:34 -0500 X-Google-Sender-Auth: QKChqxFQlq2xOjlm7bCzrNgApCE Message-ID: From: Christopher Morrow To: Eric Osterweil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Sriram, Kotikalapudi" , sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 18:41:35 -0000 On Wed, Nov 9, 2011 at 3:37 PM, Eric Osterweil wr= ote: > Hey Sriram, Russ, and Jakob, > > Thanks for the #s. =A0I think I get the general notion that adding n upda= tes per day per prefix equals (n * #prefixes)/1. :) =A0I guess my question = was kinda vague, sorry. =A0Upon reexamination, I see that I said "overhead"= without being specific. =A0Since we can use the updates that are generated= today to measure how much (for example) bandwidth is already needed, can w= e calculate how much extra bandwidth universal deployment would mean? =A0Al= so, perhaps this would be most informative in the form of a ratio (i.e. a f= actor of $x$ increase). =A0That way, when people look at events like the on= e that the "General Internet Instability" thread that just happened on NANO= G refer to, they can gauge the update amplification that was seen against w= hat _would_ be seen given bgpsec. =A0I think this actually kind of came up = on nanog, so it seems like maybe it would be a relevant thing to look at he= re? is the 'bandwidth' of the bgp protocol in the wire an actual concern? (at some point the discussion point came up ~1yr or more ago, but was discarded as not relevant given circuit sizes and bandwidth from link -> RP/RE/etc, so I'm genuinely curious about this) > > Anyway, I guess I was mostly just curious about what kinds of evaluations= have been done, thanks. :) > > Eric > > On Nov 8, 2011, at 12:19 PM, Sriram, Kotikalapudi wrote: > >> Now the ops doc has much longer beaconing interval recommendations >> for what you may consider a normal prefix. >> >> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-01#section-7 >> >> =A0 =A0 =A0 Normal Prefix: =A0Most prefixes SHOULD announce with a signa= ture >> =A0 =A0 =A0 validity of a week and beacon every three days. >> >> Sriram >> >> -----Original Message----- >> From: Jakob Heitz [mailto:jakob.heitz@ericsson.com] >> Sent: Tuesday, November 08, 2011 12:09 PM >> To: Sriram, Kotikalapudi >> Cc: Christopher Morrow; Eric Osterweil; sidr wg list >> Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs >> >> Proposal was 24 hour beacon timeout and 3 beacons per timeout. That make= s 3 beacons per day. >> >> -- >> Jakob Heitz. >> >> > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From eosterweil@verisign.com Thu Nov 10 10:46:44 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D648E21F84D4 for ; Thu, 10 Nov 2011 10:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcPkwTQ44jdf for ; Thu, 10 Nov 2011 10:46:44 -0800 (PST) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id D50D121F849C for ; Thu, 10 Nov 2011 10:46:36 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKTrwcA1uIv5cQE4BEP0eDo5wFeUsRzbU3@postini.com; Thu, 10 Nov 2011 10:46:38 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id pAAIkRb3010412; Thu, 10 Nov 2011 13:46:27 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.131.30.124]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 13:46:26 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Thu, 10 Nov 2011 13:46:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com> <92AA1C8B-7CDB-406E-AA83-7C1BCD83CB69@ericsson.com> <32DF728C-A96A-435D-A54E-7626C2577F04@verisign.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 10 Nov 2011 18:46:26.0923 (UTC) FILETIME=[0D7283B0:01CC9FD9] Cc: "Sriram, Kotikalapudi" , sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 18:46:45 -0000 On Nov 10, 2011, at 1:41 PM, Christopher Morrow wrote: > On Wed, Nov 9, 2011 at 3:37 PM, Eric Osterweil = wrote: >> Hey Sriram, Russ, and Jakob, >>=20 >> Thanks for the #s. I think I get the general notion that adding n = updates per day per prefix equals (n * #prefixes)/1. :) I guess my = question was kinda vague, sorry. Upon reexamination, I see that I said = "overhead" without being specific. Since we can use the updates that = are generated today to measure how much (for example) bandwidth is = already needed, can we calculate how much extra bandwidth universal = deployment would mean? Also, perhaps this would be most informative in = the form of a ratio (i.e. a factor of $x$ increase). That way, when = people look at events like the one that the "General Internet = Instability" thread that just happened on NANOG refer to, they can gauge = the update amplification that was seen against what _would_ be seen = given bgpsec. I think this actually kind of came up on nanog, so it = seems like maybe it would be a relevant thing to look at here? >=20 > is the 'bandwidth' of the bgp protocol in the wire an actual concern? > (at some point the discussion point came up ~1yr or more ago, but was > discarded as not relevant given circuit sizes and bandwidth from link > -> RP/RE/etc, so I'm genuinely curious about this) I think it is just a concrete way to relate the amount of data being = consumed today, to what may be needed tomorrow. It isn't so much that 1 = byte =3D good and 10 bytes =3D bad. More that in trying to quantitative = compare two behaviors, finding a common reference point seems like a = good start, imho. I think a meaningful ratio is more useful, but it = just needs something to compare. Eric From jakob.heitz@ericsson.com Thu Nov 10 10:54:34 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01AF021F8B7B for ; Thu, 10 Nov 2011 10:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.103 X-Spam-Level: X-Spam-Status: No, score=-6.103 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upBALR1a5qvk for ; Thu, 10 Nov 2011 10:54:33 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6128D21F8B7A for ; Thu, 10 Nov 2011 10:54:33 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAAIsOHV008496; Thu, 10 Nov 2011 12:54:29 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.52]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 10 Nov 2011 13:54:24 -0500 From: Jakob Heitz To: Eric Osterweil , Christopher Morrow Date: Thu, 10 Nov 2011 13:54:23 -0500 Thread-Topic: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs Thread-Index: Acyf2TAtR05Gca8ZRWqamp7nyJ4MrQAAKtLw Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A44964302@EUSAACMS0701.eamcs.ericsson.se> References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com> <92AA1C8B-7CDB-406E-AA83-7C1BCD83CB69@ericsson.com> <32DF728C-A96A-435D-A54E-7626C2577F04@verisign.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Sriram, Kotikalapudi" , sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 18:54:34 -0000 Don't forget, BGPSEC sends one prefix per update. Current traffic is 2 to 3 prefixes per update. > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf > Of Eric Osterweil > Sent: Thursday, November 10, 2011 10:46 AM > To: Christopher Morrow > Cc: Sriram, Kotikalapudi; sidr wg list > Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs >=20 >=20 > On Nov 10, 2011, at 1:41 PM, Christopher Morrow wrote: >=20 > > On Wed, Nov 9, 2011 at 3:37 PM, Eric Osterweil > wrote: > >> Hey Sriram, Russ, and Jakob, > >> > >> Thanks for the #s. I think I get the general notion that adding > n updates per day per prefix equals (n * #prefixes)/1. :) I guess > my question was kinda vague, sorry. Upon reexamination, I see that > I said "overhead" without being specific. Since we can use the > updates that are generated today to measure how much (for example) > bandwidth is already needed, can we calculate how much extra > bandwidth universal deployment would mean? Also, perhaps this would > be most informative in the form of a ratio (i.e. a factor of $x$ > increase). That way, when people look at events like the one that > the "General Internet Instability" thread that just happened on > NANOG refer to, they can gauge the update amplification that was > seen against what _would_ be seen given bgpsec. I think this > actually kind of came up on nanog, so it seems like maybe it would > be a relevant thing to look at here? > > > > is the 'bandwidth' of the bgp protocol in the wire an actual > concern? > > (at some point the discussion point came up ~1yr or more ago, but > was > > discarded as not relevant given circuit sizes and bandwidth from > link > > -> RP/RE/etc, so I'm genuinely curious about this) >=20 > I think it is just a concrete way to relate the amount of data being > consumed today, to what may be needed tomorrow. It isn't so much > that 1 byte =3D good and 10 bytes =3D bad. More that in trying to > quantitative compare two behaviors, finding a common reference point > seems like a good start, imho. I think a meaningful ratio is more > useful, but it just needs something to compare. >=20 > Eric >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From brian.peter.dickson@gmail.com Thu Nov 10 11:47:04 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A4921F8A62 for ; Thu, 10 Nov 2011 11:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tNVf7LHeS1j for ; Thu, 10 Nov 2011 11:47:03 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 99BC021F84FB for ; Thu, 10 Nov 2011 11:47:03 -0800 (PST) Received: by faas12 with SMTP id s12so3821772faa.31 for ; Thu, 10 Nov 2011 11:47:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=iAHwEQy6OIF5n6H5gkwI/TPy74R3w8CkCImyymntSZ0=; b=JBGkCTkMzPAjyC4APL0RuzPaZbyWyW1yqaqAQdX4asawn3ICJjEeun+62LGUbv6bM0 QdzN2p1wsCoDVO7hr31cZS19Q6uC6QVvZbEWqEwunyBozLp4mtp2yNVb95/6igZRBTzU XPCOGQRI32tQv1TrwRBMldvKOsxI3pSuwBIJY= MIME-Version: 1.0 Received: by 10.223.62.209 with SMTP id y17mr14024711fah.7.1320954422798; Thu, 10 Nov 2011 11:47:02 -0800 (PST) Received: by 10.223.54.15 with HTTP; Thu, 10 Nov 2011 11:47:02 -0800 (PST) In-Reply-To: References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com> Date: Thu, 10 Nov 2011 14:47:02 -0500 Message-ID: From: Brian Dickson To: "Sriram, Kotikalapudi" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 19:47:04 -0000 Hi, Sriram, Could you supply similar kinds of numbers, but with "peak" instead of "average", esp. 50%ile, 75%ile, and 95%-ile levels for "peak"? Average is much less important than peak, in my experience. Steady-state is easy. Also, in noisy/spiky data, mean !=3D median typically. BGP is noisy/spiky. (Also when doing percentiles, it is essential to say, "95%ile on 5-minute samples, over a period of 1 week" for instance - and those would be the customary sample windows to use.) Thanks, Brian On Tue, Nov 8, 2011 at 7:59 AM, Sriram, Kotikalapudi wrote: >> >> ooc, in regards to the above: is there any detailed analysis of how much= extra overhead we can expect from these beacons if BGPSec were deployed un= iversally today? =A0Specifically, the comment above, "an AS could cause the= same impact on the routing system by changing other route parameters at th= e same frequency" seems to miss the point I think I see in the objection: w= hat if _every_ AS must do this all the time (not just a rogue, or select fe= w). =A0How much extra overhead would ensue if (say) someone took the curren= t set of all ASes and prefixes and simulated the extra update traffic neede= d in (say) a day? =A0Maybe if we saw some numbers that told us how many add= itional updates and how much additional bandwidth this approach would requi= re in a routing system like today's we could understand another aspect of m= uch of a shift we are talking about? >> > > Eric, > > According to > http://bgpupdates.potaroo.net/instability/bgpupd.html > the current global BGP system produces > Average Prefixes per BGP Update: =A0 =A0 =A0 =A02.24 > Average BGP Update Messages per second: =A0 =A0 =A0 =A0 1.13 > Average Prefix Updates per second: =A0 =A0 =A02.53 > From this we can compute: > Average Prefix Updates per day =3D =A0 =A0 =A0 =A0218696 > > Now if we consider a BGPSEC island of 100,000 participating prefixes > (multiple ISPs form a BGPSEC island and there is BGPSEC between > them and also in each ISP's entire customer cone): > With 24 hour beaconing interval, we would have: > Prefix Updates per Day =3D 100,000 (seen at each BGPSEC router) > BGPSEC Update Size =3D 420B (for ECDSA-256) > Average Bandwidth Required =3D 3.89 kbps (averaged over a day) > > Does this answer what you were asking for? > > Sriram > > > > _______________________________________________ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From kent@bbn.com Thu Nov 10 13:48:21 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6621421F8505 for ; Thu, 10 Nov 2011 13:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.516 X-Spam-Level: X-Spam-Status: No, score=-106.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0I7LAWZqh45 for ; Thu, 10 Nov 2011 13:48:21 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id E134B21F8507 for ; Thu, 10 Nov 2011 13:48:20 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:41249 helo=[192.168.1.14]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1ROcTr-000NAc-Lp; Thu, 10 Nov 2011 16:48:19 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4B169301-A7C5-4C1D-B470-930DB7FBDEFF@verisign.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6025FEE@Hermes.columbia.ads.sparta.com> <4B169301-A7C5-4C1D-B470-930DB7FBDEFF@verisign.com> Date: Thu, 10 Nov 2011 16:48:11 -0500 To: Eric Osterweil From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org list" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 21:48:21 -0000 At 11:17 AM -0500 11/10/11, Eric Osterweil wrote: >On Nov 9, 2011, at 1:42 PM, Stephen Kent wrote: > >> At 1:27 AM -0500 11/8/11, Brian Dickson wrote: >>> ... >> >>> I do not support adoption of this document in its current form. >>> >>> The main reasons have to do with fundamental aspects which at a high >>> level have been addressed by my colleagues, >> >> so, this is a Verisign critique, provided by you, Eric, and Danny? > >Steve, > >This is a ridiculous question, and the implication is a completely >false characterization of my involvement. For the record: I am >participating as an individual only. > >Eric Eric, The question was not ridiculous, given the context and the terms that Brian used. Nonetheless, I accept your assertion that you are not colluding with our "colleagues." Steve From christopher.morrow@gmail.com Fri Nov 11 05:19:41 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F1521F8906 for ; Fri, 11 Nov 2011 05:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.423 X-Spam-Level: X-Spam-Status: No, score=-103.423 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XViagFMA9ft for ; Fri, 11 Nov 2011 05:19:41 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6EB21F8888 for ; Fri, 11 Nov 2011 05:19:41 -0800 (PST) Received: by ywt34 with SMTP id 34so2298261ywt.31 for ; Fri, 11 Nov 2011 05:19:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MqavDOL46myB6GdpXzY2AQDSYtwmDTe6y01Jeay37HQ=; b=E5WtrLuImjBeI/IxXFdkP6+eqQ/8BAO0vRjVWeF8pbWIZqx/e89Gia/r5UKprlEztn e7gBxwv/KSiKepiq2hYnrBKCpvSOLlRYQ7pibIgDyN3BowFney8loBe8BXiAvrXq0n5J P1ROHxtjWxxMcCpQwt6IbF75uSI27QMqZQUJY= MIME-Version: 1.0 Received: by 10.50.184.202 with SMTP id ew10mr12344671igc.48.1321017580783; Fri, 11 Nov 2011 05:19:40 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Fri, 11 Nov 2011 05:19:40 -0800 (PST) In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A44964302@EUSAACMS0701.eamcs.ericsson.se> References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com> <92AA1C8B-7CDB-406E-AA83-7C1BCD83CB69@ericsson.com> <32DF728C-A96A-435D-A54E-7626C2577F04@verisign.com> <7309FCBCAE981B43ABBE69B31C8D21391A44964302@EUSAACMS0701.eamcs.ericsson.se> Date: Fri, 11 Nov 2011 08:19:40 -0500 X-Google-Sender-Auth: H-D5PEwVflKlKEthm2aNZGhkmDU Message-ID: From: Christopher Morrow To: Jakob Heitz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Sriram, Kotikalapudi" , sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 13:19:42 -0000 On Thu, Nov 10, 2011 at 1:54 PM, Jakob Heitz wro= te: > Don't forget, BGPSEC sends one prefix per update. > Current traffic is 2 to 3 prefixes per update. There's actually some research on this, I recall the number 'globally' as 1.2 avg packing... but internally, that may be different, of course. -chris >> -----Original Message----- >> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf >> Of Eric Osterweil >> Sent: Thursday, November 10, 2011 10:46 AM >> To: Christopher Morrow >> Cc: Sriram, Kotikalapudi; sidr wg list >> Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs >> >> >> On Nov 10, 2011, at 1:41 PM, Christopher Morrow wrote: >> >> > On Wed, Nov 9, 2011 at 3:37 PM, Eric Osterweil >> wrote: >> >> Hey Sriram, Russ, and Jakob, >> >> >> >> Thanks for the #s. =A0I think I get the general notion that adding >> n updates per day per prefix equals (n * #prefixes)/1. :) =A0I guess >> my question was kinda vague, sorry. =A0Upon reexamination, I see that >> I said "overhead" without being specific. =A0Since we can use the >> updates that are generated today to measure how much (for example) >> bandwidth is already needed, can we calculate how much extra >> bandwidth universal deployment would mean? =A0Also, perhaps this would >> be most informative in the form of a ratio (i.e. a factor of $x$ >> increase). =A0That way, when people look at events like the one that >> the "General Internet Instability" thread that just happened on >> NANOG refer to, they can gauge the update amplification that was >> seen against what _would_ be seen given bgpsec. =A0I think this >> actually kind of came up on nanog, so it seems like maybe it would >> be a relevant thing to look at here? >> > >> > is the 'bandwidth' of the bgp protocol in the wire an actual >> concern? >> > (at some point the discussion point came up ~1yr or more ago, but >> was >> > discarded as not relevant given circuit sizes and bandwidth from >> link >> > -> RP/RE/etc, so I'm genuinely curious about this) >> >> I think it is just a concrete way to relate the amount of data being >> consumed today, to what may be needed tomorrow. =A0It isn't so much >> that 1 byte =3D good and 10 bytes =3D bad. =A0More that in trying to >> quantitative compare two behaviors, finding a common reference point >> seems like a good start, imho. =A0I think a meaningful ratio is more >> useful, but it just needs something to compare. >> >> Eric >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > From danny@tcb.net Fri Nov 11 05:52:00 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21AF21F8663 for ; Fri, 11 Nov 2011 05:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.346 X-Spam-Level: X-Spam-Status: No, score=-102.346 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clURqYj1gOFB for ; Fri, 11 Nov 2011 05:52:00 -0800 (PST) Received: from uu.ops-netman.net (morrowc-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:36e::2]) by ietfa.amsl.com (Postfix) with ESMTP id BF02521F8463 for ; Fri, 11 Nov 2011 05:51:59 -0800 (PST) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [208.76.12.119]) by uu.ops-netman.net (Postfix) with ESMTP id 8889319002F; Fri, 11 Nov 2011 13:51:54 +0000 (UTC) Received: from dul1dmcphers-m1.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (Authenticated sender: danny@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 590073202A2; Fri, 11 Nov 2011 13:51:48 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2--885201545 From: Danny McPherson In-Reply-To: Date: Fri, 11 Nov 2011 08:49:41 -0500 Message-Id: References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com> <92AA1C8B-7CDB-406E-AA83-7C1BCD83CB69@ericsson.com> <32DF728C-A96A-435D-A54E-7626C2577F04@verisign.com> <7309FCBCAE981B43ABBE69B31C8D21391A44964302@EUSAACMS0701.eamcs.ericsson.se> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) Cc: Kotikalapudi Sriram , sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 13:52:01 -0000 --Apple-Mail-2--885201545 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Nov 11, 2011, at 8:19 AM, Christopher Morrow wrote: > > There's actually some research on this, I recall the number 'globally' > as 1.2 avg packing... but internally, that may be different, of > course. I'd be interested in a pointer to that Chris, if you could pass it along. The only quantitative analysis I've seen of this is here: It's 3 months of data from 6 monitors. The basic observation is that around 30% to 40% updates are packed, and these packed updates carry up to 80% of prefixes -- a density that seems to be fairly consistent across both iBGP and eBGP monitors. -danny --Apple-Mail-2--885201545 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
There's = actually some research on this, I recall the number 'globally'
as 1.2 = avg packing... but internally, that may be different, = of
course.

I'd be interested in a = pointer to that Chris, if you could pass it = along.

The only quantitative analysis I've seen = of this is here:


It's 3 months = of data from 6 monitors.  The basic observation is = that 
around 30% to 40% updates are packed, and = these packed updates 
carry up to 80% of prefixes -- a = density that seems to be fairly = consistent 
across both iBGP and eBGP = monitors.

-danny
= --Apple-Mail-2--885201545-- From christopher.morrow@gmail.com Fri Nov 11 08:45:44 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4EAF21F8A62 for ; Fri, 11 Nov 2011 08:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.421 X-Spam-Level: X-Spam-Status: No, score=-103.421 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjpBAqWwxU1w for ; Fri, 11 Nov 2011 08:45:43 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E55121F87FA for ; Fri, 11 Nov 2011 08:45:43 -0800 (PST) Received: by ggnr4 with SMTP id r4so3346115ggn.31 for ; Fri, 11 Nov 2011 08:45:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/PDduo0EnAcfAPmgtgOD1cOL6f0Iccl5Ln0UrPl8stU=; b=MtTOLBfHMbeLcokc0b8R4We5XANAiX/bQbSHab/MZ1YA67GuCGXMhHodH6cKHXbxEE 2d5FlLSfA2MLMeiiW9mcsXiIp5q2tFK8BXl4eYzp7ax9U4XbEBxx5+OYbxDN7ZzrYI1i LRc0ZcoQwTAQN+cKBGZV77rv0fZJnKDD6jf+g= MIME-Version: 1.0 Received: by 10.50.42.198 with SMTP id q6mr13559166igl.34.1321029942309; Fri, 11 Nov 2011 08:45:42 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Fri, 11 Nov 2011 08:45:42 -0800 (PST) In-Reply-To: References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com> <92AA1C8B-7CDB-406E-AA83-7C1BCD83CB69@ericsson.com> <32DF728C-A96A-435D-A54E-7626C2577F04@verisign.com> <7309FCBCAE981B43ABBE69B31C8D21391A44964302@EUSAACMS0701.eamcs.ericsson.se> Date: Fri, 11 Nov 2011 11:45:42 -0500 X-Google-Sender-Auth: 9D235BzpptryZDJY5tAyHbTc8zg Message-ID: From: Christopher Morrow To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kotikalapudi Sriram , sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 16:45:44 -0000 On Fri, Nov 11, 2011 at 8:49 AM, Danny McPherson wrote: > > On Nov 11, 2011, at 8:19 AM, Christopher Morrow wrote: > > There's actually some research on this, I recall the number 'globally' > as 1.2 avg packing... but internally, that may be different, of > course. > > I'd be interested in a pointer to that Chris, if you could pass it along. I had thought randy referenced the thing I am remembering, I'll ask once I get to the meeting venue. I think he's also pointed to some study work on the effect of ingesting 1x prefix vs packed prefixes... > The only quantitative analysis I've seen of this is here: > > It's 3 months of data from 6 monitors. =A0The basic observation is that > around 30% to 40% updates are packed,=A0and these packed updates > carry up to 80% of prefixes -- a density that seems to be fairly consiste= nt > across=A0both iBGP and eBGP monitors. neat. > -danny From kotikalapudi.sriram@nist.gov Fri Nov 11 09:07:44 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3710721F8AD9 for ; Fri, 11 Nov 2011 09:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.429 X-Spam-Level: X-Spam-Status: No, score=-6.429 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aYdM-Kh962g for ; Fri, 11 Nov 2011 09:07:43 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 4120F21F8AD8 for ; Fri, 11 Nov 2011 09:07:43 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 11 Nov 2011 12:07:32 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 11 Nov 2011 12:07:41 -0500 From: "Sriram, Kotikalapudi" To: Christopher Morrow , Danny McPherson Date: Fri, 11 Nov 2011 12:07:04 -0500 Thread-Topic: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs Thread-Index: AcygkUU9SYvC7/xgSBiZpt6hjdZBRgAAXZY/ Message-ID: References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com> <92AA1C8B-7CDB-406E-AA83-7C1BCD83CB69@ericsson.com> <32DF728C-A96A-435D-A54E-7626C2577F04@verisign.com> <7309FCBCAE981B43ABBE69B31C8D21391A44964302@EUSAACMS0701.eamcs.ericsson.se> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 17:07:44 -0000 You may have missed noticing it... I had provided the reference and the numbers in my eralier email -- http://www.ietf.org/mail-archive/web/sidr/current/msg03586.html According to http://bgpupdates.potaroo.net/instability/bgpupd.html the current global BGP system produces __ Average Prefixes per BGP Update: 2.24 __ Average BGP Update Messages per second: 1.13 Average Prefix Updates per second: 2.53 >From this we can compute: Average Prefix Updates per day = 218696 So yes, I did consider the _prefix _ updates as is the case in BGPSEC (not updates with packing in it). Sriram ________________________________________ From: christopher.morrow@gmail.com [christopher.morrow@gmail.com] On Behalf Of Christopher Morrow [morrowc.lists@gmail.com] Sent: Friday, November 11, 2011 11:45 AM To: Danny McPherson Cc: Jakob Heitz; Sriram, Kotikalapudi; sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs On Fri, Nov 11, 2011 at 8:49 AM, Danny McPherson wrote: > > On Nov 11, 2011, at 8:19 AM, Christopher Morrow wrote: > > There's actually some research on this, I recall the number 'globally' > as 1.2 avg packing... but internally, that may be different, of > course. > > I'd be interested in a pointer to that Chris, if you could pass it along. I had thought randy referenced the thing I am remembering, I'll ask once I get to the meeting venue. I think he's also pointed to some study work on the effect of ingesting 1x prefix vs packed prefixes... > The only quantitative analysis I've seen of this is here: > > It's 3 months of data from 6 monitors. The basic observation is that > around 30% to 40% updates are packed, and these packed updates > carry up to 80% of prefixes -- a density that seems to be fairly consistent > across both iBGP and eBGP monitors. neat. > -danny From Sandra.Murphy@cobham.com Fri Nov 11 12:48:07 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64ECD21F8B65 for ; Fri, 11 Nov 2011 12:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70pKwaKe0-HM for ; Fri, 11 Nov 2011 12:48:06 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6047721F8B64 for ; Fri, 11 Nov 2011 12:48:06 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id pABKlheL002527; Fri, 11 Nov 2011 14:47:43 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id pABKlh4K019504; Fri, 11 Nov 2011 14:47:43 -0600 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0339.001; Fri, 11 Nov 2011 15:47:24 -0500 From: "Murphy, Sandra" To: Brian Dickson , Stephen Kent Thread-Topic: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 Thread-Index: AQHMnxsyCx2p0PZ7Tu6Ty5HU0UcysZWnVAyU Date: Fri, 11 Nov 2011 20:47:23 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6028DB8@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6025FEE@Hermes.columbia.ads.sparta.com> , In-Reply-To: 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 Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 20:48:07 -0000 Guys, guys, guys.=0A= =0A= Steve: making reference to a person's company concentrates too much on the = personal. Please be more careful.=0A= =0A= Brian, Eric: If you meant "some individual contributors who I happen to k= now and discuss this with", saying "my colleagues" was subject to misinterp= retation, especially in light of this recent energetic exchange. =0A= =0A= --Sandy, speaking out for civility as wg chair=0A= =0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Eric Oster= weil [eosterweil@verisign.com]=0A= Sent: Thursday, November 10, 2011 11:17 AM=0A= To: Stephen Kent=0A= Cc: sidr@ietf.org list=0A= Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03=0A= =0A= On Nov 9, 2011, at 1:42 PM, Stephen Kent wrote:=0A= =0A= > At 1:27 AM -0500 11/8/11, Brian Dickson wrote:=0A= >> ...=0A= >=0A= >> I do not support adoption of this document in its current form.=0A= >>=0A= >> The main reasons have to do with fundamental aspects which at a high=0A= >> level have been addressed by my colleagues,=0A= >=0A= > so, this is a Verisign critique, provided by you, Eric, and Danny?=0A= =0A= Steve,=0A= =0A= This is a ridiculous question, and the implication is a completely false ch= aracterization of my involvement. For the record: I am participating as an= individual only.=0A= =0A= Eric=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Brian Dick= son [brian.peter.dickson@gmail.com]=0A= Sent: Wednesday, November 09, 2011 3:07 PM=0A= To: Stephen Kent=0A= Cc: sidr@ietf.org=0A= Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03=0A= =0A= On Wed, Nov 9, 2011 at 1:42 PM, Stephen Kent wrote:=0A= > At 1:27 AM -0500 11/8/11, Brian Dickson wrote:=0A= >=0A= > ...=0A= >=0A= > I do not support adoption of this document in its current form.=0A= >=0A= > The main reasons have to do with fundamental aspects which at a high=0A= >=0A= > level have been addressed by my colleagues,=0A= >=0A= > so, this is a Verisign critique, provided by you, Eric, and Danny?=0A= =0A= Respectfully, Stephen, I would ask that you not infer anything along=0A= these lines.=0A= The IETF is very clear on participation being an individual activity,=0A= regardless of=0A= $day_job.=0A= =0A= In addition to this _not_ being the case, I _personally_ consider this both= =0A= highly inappropriate at a professional level, and bordering on _ad_hominem_= ,=0A= something that really has no place in WG mailing-list discussions.=0A= =0A= I would ask that you seriously consider whether an apology for your comment= =0A= is appropriate.=0A= =0A= As for "colleague", I meant within the WG, as in "collegial". If I had mean= t to=0A= say "co-worker", I would have said "co-worker".=0A= =0A= Any similarity between our concerns is entirely due to similarity in operat= ional=0A= experiences in a variety of venues, at a variety of $day_jobs.=0A= =0A= I'll address the content-oriented portion of your email in a separate messa= ge.=0A= =0A= Brian=0A= - not using any email-address that would suggest affiliation -=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From Sandra.Murphy@cobham.com Fri Nov 11 12:53:20 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B6C21F8B70 for ; Fri, 11 Nov 2011 12:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+2bu+XCvnmv for ; Fri, 11 Nov 2011 12:53:20 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 44E5221F8B6F for ; Fri, 11 Nov 2011 12:53:19 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id pABKrIPk002555 for ; Fri, 11 Nov 2011 14:53:18 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id pABKrHXh019553 for ; Fri, 11 Nov 2011 14:53:17 -0600 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0339.001; Fri, 11 Nov 2011 15:53:17 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: presentations, jabber scribe and minute taker Thread-Index: Acygsp9Qv7mz9gyGQhaEuo8yB63HNA== Date: Fri, 11 Nov 2011 20:53:15 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6030A26@Hermes.columbia.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_24B20D14B2CD29478C8D5D6E9CBB29F6030A26Hermescolumbiaads_" MIME-Version: 1.0 Subject: [sidr] presentations, jabber scribe and minute taker X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 20:53:20 -0000 --_000_24B20D14B2CD29478C8D5D6E9CBB29F6030A26Hermescolumbiaads_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Those who have slots for presentation at the sidr meeting please send slide= s to both chairs by Tuesday morning. Despite similar requests in the past, we seem to frequently have presentati= ons that show up during the meeting. Please do not do that. Presentations= must be uploaded for everyone to view, especially those who are participat= ing remotely. The chairs may not be able to accommodate your presentation = if it arrives late. We also need a jabber scribe and minute taker. The chairs very much apprec= iate the time and trouble of previous volunteers. Please give thought to d= oing your part this time. (Maybe there should be candy prizes.) Use of the new etherpad collaborative tool for minutes taking is possible i= f any want to try it but is not required. --Sandy, speaking as wg chair --_000_24B20D14B2CD29478C8D5D6E9CBB29F6030A26Hermescolumbiaads_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Those who have slots for presentation at the sidr meeting please sen= d slides to both chairs by Tuesday morning.

Despite similar requests in the past, we seem to frequently have presentati= ons that show up during the meeting.  Please do not do that.  Pre= sentations must be uploaded for everyone to view, especially those who are = participating remotely.  The chairs may not be able to accommodate your presentation if it arrives late.

We also need a jabber scribe and minute taker.  The chairs very much a= ppreciate the time and trouble of previous volunteers.  Please give th= ought to doing your part this time.  (Maybe there should be candy priz= es.)

Use of the new etherpad collaborative tool for minutes taking is possible i= f any want to try it but is not required.

--Sandy, speaking as wg chair
--_000_24B20D14B2CD29478C8D5D6E9CBB29F6030A26Hermescolumbiaads_-- From wesley.george@twcable.com Fri Nov 11 16:52:02 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885AB1F0C38 for ; Fri, 11 Nov 2011 16:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.306 X-Spam-Level: X-Spam-Status: No, score=-0.306 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbCrMk0QM5Au for ; Fri, 11 Nov 2011 16:52:02 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id C24771F0C36 for ; Fri, 11 Nov 2011 16:52:01 -0800 (PST) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,496,1315195200"; d="scan'208";a="281270778" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 11 Nov 2011 19:47:14 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Fri, 11 Nov 2011 19:52:01 -0500 From: "George, Wes" To: Matt Lepinski , "sidr@ietf.org" Date: Fri, 11 Nov 2011 19:52:21 -0500 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-01.txt Thread-Index: AcyYt+wQxmK1uFpBRxK/ph84RiL4VAHat99w Message-ID: References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com> In-Reply-To: <4EB02586.5010101@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 00:52:02 -0000 > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Matt Lepinski > The -01 > version of the draft contains a mechanism (a field called pCount) > which attempts to address this issue by having route servers create > BGPSEC signatures without increasing the effective length of the AS- > PATH attribute. [WEG] where you explain the pCount field in both section 3 and 4.1, you nev= er explicitly state anything about the route-server use case. In those sect= ions, you only discuss the case where this is used to eliminate the need fo= r duplicate signatures in the case of AS-path prepending. I think that sect= ion 3's explanation of the field definitely needs a reference to 4.1 and 4.= 2, and since 4.2 contains a backward reference to 4.1 explaining pCount>1, = 4.1 should probably have a corresponding reference to 4.2 for pCount=3D0. I= t may also be appropriate to explicitly state in 4.1 that when a node sets = the pCount to a value greater than 1, that value MUST correspond to the num= ber of instances of the AS-path being represented in BGP's standard AS/AS4_= path attribute. Some other general comments- as I noted in my review of the requirements document, I think that it's app= ropriate to note in this document an explicit requirement for 4-byte ASN su= pport, including any discussion of how to handle 4-byte ASNs, as well as re= commend explicit handling for occurrences of AS23456 in the path (eg, becau= se we should be acting on the 4-byte ASN, we should never see the transitio= n ASN in the path, and therefore those updates should always be seen as inv= alid). 4.2 - AS_SETs are deprecated. You should update your discussion accordingly= , with a reference to whatever RFC draft-ietf-idr-deprecate-as-sets-06 beca= me (I'm writing this offline, so I don't have the ability to find the numbe= r). 5.1 - Is the algorithm intended to be processed strictly in the order liste= d? Specifically, both in terms of the items preceded with "first, second, t= hird, finally..." and within the multi-step subsection covering determining= if updates are properly formed, it is unclear whether this is simply an ar= bitrary grammatical list grouping for ease of reading, or if it is an expli= citly defined order. I would prefer that it either explicitly states that i= t requires the order listed (with justification/rationale as appropriate) o= r to explicitly note that the order is left to the implementation so that o= ptimizations can be made based on the specific implementation. It may also = be worth noting the places where there is no dependency between validation = steps so that they can be processed in parallel on separate threads (such a= s when optimizing for multi-core applications). Also, shouldn't there be a = reference to the origin validation documents instead of an explanation of h= ow to do origin validation? Regarding confederations - what if one or more of the confeds is a private = ASN? This is maybe a bit more straightforward if you're in the situation wh= ere AS1 learns the route originated from a private ASN in confederation, as= it could simply originate/sign the route to its ebgp peers directly. It's = more complicated (I think...) if the confed ASes are in the middle of the p= ath (that is, the private ASN learns the route from a downstream ASN and th= en propagates it to the upstream confed peer) because there's not really a = way to drop signatures from the middle of the path, yet the private ASNs ar= e going to be stripped out of the BGP update messages as it leaves the conf= ederation. Perhaps this is another case where the pCount should be 0? Is th= ere any other special handling for confed? Alternatively, we may have to ex= plicitly prohibit this setup similar to the way that we did with AS_Set. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wesley.george@twcable.com Fri Nov 11 17:02:39 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54C71F0C3B for ; Fri, 11 Nov 2011 17:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8h3r2yVg4-D for ; Fri, 11 Nov 2011 17:02:38 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id C362C1F0C36 for ; Fri, 11 Nov 2011 17:02:38 -0800 (PST) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,496,1315195200"; d="scan'208";a="281272691" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 11 Nov 2011 19:57:51 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Fri, 11 Nov 2011 20:02:38 -0500 From: "George, Wes" To: Jakob Heitz , Eric Osterweil , "Sriram, Kotikalapudi" Date: Fri, 11 Nov 2011 20:02:59 -0500 Thread-Topic: Beacons in a separate TCP Thread-Index: AcyfLDg0j50Bi0neROCKFI3By4evPAA6KGgw Message-ID: References: <7309FCBCAE981B43ABBE69B31C8D21391A44963DA0@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A44963DA0@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] Beacons in a separate TCP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 01:02:39 -0000 > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Jakob Heitz > > The beacons will be unlikely to come like the slow constant drizzle of > Seattle weather, but more like the quick cloudbursts of Miami weather. > Just guessing. > > Such beacons will cause head-of-line blocking for more urgent updates > behind them. Beacons can be delayed for hours without consequence. Not > so for other updates. > > I think beacons should be transmitted in a TCP session separate from > the normal BGP traffic, so as not to delay that. [WEG] I'm not certain I understand how a separate TCP session would make a = significant difference. When the update arrives, the router has to do somet= hing to it, either process it or slap it into a buffer (RAM or hard drive) = for processing when it's less busy. You could accomplish the same thing by flagging it with different QOS value= s, instructing the beacon sender to send the updates at pseudo-random inter= vals, and instructing the receiving router to always process update/withdra= w messages before beacons, right? But really, this just ends up being part = of the overall base CPU load of the BGPSec implementation. Either the routi= ng system hardware has the scale to run it or it doesn't. If we're down to = having to use separate TCP sessions to segregate important updates from les= s important ones, we have a larger problem IMO. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From jakob.heitz@ericsson.com Fri Nov 11 17:24:29 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFA41F0C3D for ; Fri, 11 Nov 2011 17:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.236 X-Spam-Level: X-Spam-Status: No, score=-6.236 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9c4rULyUB7Ok for ; Fri, 11 Nov 2011 17:24:28 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6895C1F0C3B for ; Fri, 11 Nov 2011 17:24:28 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAC1ONdv006877; Fri, 11 Nov 2011 19:24:24 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.52]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 11 Nov 2011 20:24:23 -0500 From: Jakob Heitz To: "George, Wes" Date: Fri, 11 Nov 2011 20:25:02 -0500 Thread-Topic: Beacons in a separate TCP Thread-Index: Acyg2c84UnSjpaBxS/qoOOzZmhgrFA== Message-ID: <34A0153E-578B-4E98-B055-5155798B235F@ericsson.com> References: <7309FCBCAE981B43ABBE69B31C8D21391A44963DA0@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Sriram, Kotikalapudi" , sidr wg list Subject: Re: [sidr] Beacons in a separate TCP X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 01:24:29 -0000 If the router has other work, it can simply stop reading the tcp socket. Th= at would put the tcp into persist state and the sender will stop sending. T= his is only possible if the beacons are in a separate tcp session. -- Jakob Heitz. On Nov 11, 2011, at 5:02 PM, "George, Wes" wrot= e: >> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of >> Jakob Heitz >>=20 >> The beacons will be unlikely to come like the slow constant drizzle of >> Seattle weather, but more like the quick cloudbursts of Miami weather. >> Just guessing. >>=20 >> Such beacons will cause head-of-line blocking for more urgent updates >> behind them. Beacons can be delayed for hours without consequence. Not >> so for other updates. >>=20 >> I think beacons should be transmitted in a TCP session separate from >> the normal BGP traffic, so as not to delay that. >=20 > [WEG] I'm not certain I understand how a separate TCP session would make = a significant difference. When the update arrives, the router has to do som= ething to it, either process it or slap it into a buffer (RAM or hard drive= ) for processing when it's less busy. > You could accomplish the same thing by flagging it with different QOS val= ues, instructing the beacon sender to send the updates at pseudo-random int= ervals, and instructing the receiving router to always process update/withd= raw messages before beacons, right? But really, this just ends up being par= t of the overall base CPU load of the BGPSec implementation. Either the rou= ting system hardware has the scale to run it or it doesn't. If we're down t= o having to use separate TCP sessions to segregate important updates from l= ess important ones, we have a larger problem IMO. >=20 > Wes George >=20 > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. From randy@psg.com Fri Nov 11 19:40:55 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6232F1F0C3D for ; Fri, 11 Nov 2011 19:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38A4+WzfuxKH for ; Fri, 11 Nov 2011 19:40:55 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 080E81F0C38 for ; Fri, 11 Nov 2011 19:40:55 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RP4Sb-000Kab-8L; Sat, 12 Nov 2011 03:40:53 +0000 Date: Sat, 12 Nov 2011 11:40:52 +0800 Message-ID: From: Randy Bush To: Wesley George In-Reply-To: References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: [sidr] various X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 03:40:55 -0000 to two of your comments, in my unpublished edit buffers draft-ietf-sidr-bgpsec-ops-02 To prevent exposure of the internals of BGP Confederations [RFC5065], a BGPsec speaker which is a Member-AS of a Confederation MUST NOT not sign updates sent to another Member-AS of the same Confederation. draft-ietf-sidr-pfx-validate-04 An implementation MUST support 4 Octet AS Numbers, [RFC4893]. as our friendly blood-sucking vendors have said, the latter is thought to be obvious. but i figured to document it anyway, no harm. cool? randy From wesley.george@twcable.com Fri Nov 11 21:40:51 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8981F0C4F for ; Fri, 11 Nov 2011 21:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Vaz3fmqBPOo for ; Fri, 11 Nov 2011 21:40:51 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 014B41F0C3C for ; Fri, 11 Nov 2011 21:40:50 -0800 (PST) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,498,1315195200"; d="scan'208";a="281299858" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 12 Nov 2011 00:36:02 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Sat, 12 Nov 2011 00:40:49 -0500 From: "George, Wes" To: Randy Bush Date: Sat, 12 Nov 2011 00:41:10 -0500 Thread-Topic: various Thread-Index: Acyg7OK1AuGT5SM6Q/eB0ZwemBiAlAAAxTMA Message-ID: References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] various X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 05:40:51 -0000 > From: Randy Bush [mailto:randy@psg.com] > Sent: Friday, November 11, 2011 10:41 PM > To: George, Wes > Cc: sidr wg list > Subject: various > > draft-ietf-sidr-bgpsec-ops-02 > > To prevent exposure of the internals of BGP Confederations > [RFC5065], > a BGPsec speaker which is a Member-AS of a Confederation MUST NOT > not > sign updates sent to another Member-AS of the same Confederation. > [WEG] does that mean that routes using confeds as transit ASes cannot parti= cipate in BGPSec at all? (eg if the update path goes: Origin ASN -> confed AS ($private) -> confed AS ($public) -> eBGP peer) If that's the case, would be useful to be more explicit about it. Or do you mean that confed AS1 will not be in the signature chain/AS path a= nd the public ASBR (the external side of the confed) will sign as if it lea= rned the routes directly from the Origin ASN? If it's the latter, you proba= bly need more clarifying text, and that may actually require some text in t= he protocol definition to cover the special-case handling. Related: It may be that we have to simply say that Private ASNs can't be BG= PSec participants, whether in confeds or otherwise, for many of the same re= asons - AFAICT it'd be impossible to build a signature path and then update= it downstream to reflect the external AS it gets replaced with. > draft-ietf-sidr-pfx-validate-04 > > An implementation MUST support 4 Octet AS Numbers, [RFC4893]. > > as our friendly blood-sucking vendors have said, the latter is thought > to be obvious. but i figured to document it anyway, no harm. > > cool? [WEG] works for me! Wes This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From randy@psg.com Fri Nov 11 22:49:57 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4698221F84D2 for ; Fri, 11 Nov 2011 22:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaYQpEaysa5K for ; Fri, 11 Nov 2011 22:49:56 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 8451121F84D1 for ; Fri, 11 Nov 2011 22:49:56 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RP7PX-000KsN-4Z; Sat, 12 Nov 2011 06:49:55 +0000 Date: Sat, 12 Nov 2011 14:49:54 +0800 Message-ID: From: Randy Bush To: "George, Wes" In-Reply-To: References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] various X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 06:49:57 -0000 >> draft-ietf-sidr-bgpsec-ops-02 >> >> To prevent exposure of the internals of BGP Confederations [RFC5065], >> a BGPsec speaker which is a Member-AS of a Confederation MUST NOT >> sign updates sent to another Member-AS of the same Confederation. > > [WEG] does that mean that routes using confeds as transit ASes cannot > participate in BGPSec at all? no. and it does not in any way say that, does it? > (eg if the update path goes: > Origin ASN -> confed AS ($private) -> confed AS ($public) -> eBGP peer) > If that's the case, would be useful to be more explicit about it. the statement attempts to very clearly apply ONLY to two members of the confed speaking to each other, period. if it is not clearly restricted to that case, please say how it could be reworded to more clearly be so restricted. ( i should be able to differentiate you and shane. he sends text :) > Or do you mean that confed AS1 will not be in the signature chain/AS > path and the public ASBR (the external side of the confed) will sign > as if it learned the routes directly from the Origin ASN? if bt AS1 you mean what you call "AS ($private)" above, yes, that is what is meant. > If it's the latter, you probably need more clarifying text, and that > may actually require some text in the protocol definition to cover the > special-case handling. why is it needed to cross over into the large space of what is to be signed? the point of the bullet is what is NOT to be signed. > Related: It may be that we have to simply say that Private ASNs can't > be BGPSec participants tell that to someone trying to secure some multi-as private network using rfc 1918 addresses and asns. randy From kent@bbn.com Sat Nov 12 00:28:05 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA3821F8713 for ; Sat, 12 Nov 2011 00:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.519 X-Spam-Level: X-Spam-Status: No, score=-106.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmzvFp5O3oAj for ; Sat, 12 Nov 2011 00:28:05 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 781ED21F86AA for ; Sat, 12 Nov 2011 00:28:05 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:39261 helo=[10.59.77.141]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RP8wV-000I2n-Bh; Sat, 12 Nov 2011 03:28:03 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6028DB8@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6025FEE@Hermes.columbia.ads.sparta.com> , <24B20D14B2CD29478C8D5D6E9CBB29F6028DB8@Hermes.columbia.ads.sparta.com> Date: Sat, 12 Nov 2011 03:13:31 -0500 To: "Murphy, Sandra" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 08:28:06 -0000 At 8:47 PM +0000 11/11/11, Murphy, Sandra wrote: >Guys, guys, guys. Steve: making reference to a person's company >concentrates too much on the personal. Please be more careful. >Brian, Eric: If you meant "some individual contributors who I >happen to know and discuss this with", saying "my colleagues" was >subject to misinterpretation, especially in light of this recent >energetic exchange. --Sandy, speaking out for civility as wg chair I concur with your dual observations above. Hope we can now move ahead with the discussions. Steve From wesley.george@twcable.com Sat Nov 12 02:18:33 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364D621F84A0 for ; Sat, 12 Nov 2011 02:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.85 X-Spam-Level: X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOWs-eG0hhRp for ; Sat, 12 Nov 2011 02:18:32 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECB221F858C for ; Sat, 12 Nov 2011 02:18:32 -0800 (PST) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,498,1315195200"; d="scan'208";a="296595805" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 12 Nov 2011 05:14:00 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Sat, 12 Nov 2011 05:18:23 -0500 From: "George, Wes" To: Randy Bush Date: Sat, 12 Nov 2011 05:18:44 -0500 Thread-Topic: various Thread-Index: AcyhB0sSmc5HaS98SrSpMH6sYMWKCwAESHew Message-ID: References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] various X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 10:18:33 -0000 > From: Randy Bush [mailto:randy@psg.com] > > the statement attempts to very clearly apply ONLY to two members of the > confed speaking to each other, period. if it is not clearly restricted > to that case, please say how it could be reworded to more clearly be so > restricted. > > ( i should be able to differentiate you and shane. he sends text :) [WEG] ouch. Cut a mental midget some slack as he attempts to understand wel= l enough to know if he needs to propose new text. :-) That's very clear by itself. What was (and is) less clear is how that inter= acts with the rest of the network. More on that below. > > > Or do you mean that confed AS1 will not be in the signature chain/AS > > path and the public ASBR (the external side of the confed) will sign > > as if it learned the routes directly from the Origin ASN? > > if bt AS1 you mean what you call "AS ($private)" above, yes, that is > what is meant. [WEG] ok, given that, I can suggest text to add to what you've already prop= osed - "However, signed updates received from BGPSec speakers outside of the confe= deration (i.e. those transiting the confederation ASes) MUST be passed to t= he other Member-ASes BGPSec speakers intact. This will allow those speakers= to sign updates to their eBGP peers using the confederation identifier ASN= and give a complete chain of signatures as if the confederation were a sin= gle ASN." > > Related: It may be that we have to simply say that Private ASNs can't > > be BGPSec participants > > tell that to someone trying to secure some multi-as private network > using rfc 1918 addresses and asns. [WEG] you know I debated making a clarifying exception to the above case wh= en I wrote this mail, but I figured it'd be clear from the above discussion= that I was talking about the application where the routes need to be annou= nced into the DFZ, not the case of using your own TA/private space to secur= e a completely private network with this machinery. If you're using Private ASNs either as origin or as transit for something t= hat has to be announced to the rest of the world, today you can do things l= ike replace-AS, remove-private-as, or you can re-originate it from a public= ASN (network statements, etc). In this context, Re-origination should work= , but I'm thinking that replace-AS/remove-private will not, unless you also= strip the signatures for everything behind the ASN you're replacing, and o= nly sign from that point outward. In other words, you can break the chain o= f signatures and start a new one, but you can't "fix" the existing signatur= es. Perhaps that's obvious to everyone involved in the implementation, but = it was not obvious to me until I thought through it. Text might take the form of: "If a BGPSec speaker receives updates from ano= ther BGPSec speaker with a Private ASN in the path, and is configured to st= rip those private ASN(s) from updates to its eBGP peers, it MUST also strip= any BGPSec signatures contained in that update before signing the update a= nd announcing it to its eBGP peers, even if the eBGP peer is a BGPSec speak= er. This is to prevent exposing internal ASNs outside of the network where = they are being used." Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From randy@psg.com Sat Nov 12 02:45:29 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B2D21F899F for ; Sat, 12 Nov 2011 02:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80ljdxjGeQir for ; Sat, 12 Nov 2011 02:45:28 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA6E21F8797 for ; Sat, 12 Nov 2011 02:45:28 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RPB5T-000LJe-BB; Sat, 12 Nov 2011 10:45:27 +0000 Date: Sat, 12 Nov 2011 18:45:26 +0800 Message-ID: From: Randy Bush To: Wesley George In-Reply-To: References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] various X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 10:45:29 -0000 > "However, signed updates received from BGPSec speakers outside of the > confederation (i.e. those transiting the confederation ASes) MUST be > passed to the other Member-ASes BGPSec speakers intact. nope. you could decide to strip toward one or more confed peers which are not bgpsec capable. your routers, your decision, your policy. don't go there. the rule was very intentionally precise and simple, two members of the same confderation must not add sigs toward each other. imiho, saying anything more is either adding unnecessary words at best or opening up large complexity holes at worst. >> tell that to someone trying to secure some multi-as private network >> using rfc 1918 addresses and asns. > [WEG] you know I debated making a clarifying exception to the above i try to minimize statements that require clarifying exceptions. they tend to open primrose paths with no proof of termination. > I figured it'd be clear from the above discussion and yet you want to me to go into unnecessary complications not directly needed given my brutally specific statement? :) randy From wesley.george@twcable.com Sat Nov 12 04:56:58 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FB021F84A5 for ; Sat, 12 Nov 2011 04:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.363 X-Spam-Level: X-Spam-Status: No, score=-0.363 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Vn2Njhw1048 for ; Sat, 12 Nov 2011 04:56:57 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5777C21F847F for ; Sat, 12 Nov 2011 04:56:57 -0800 (PST) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,498,1315195200"; d="scan'208";a="281339909" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 12 Nov 2011 07:52:08 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Sat, 12 Nov 2011 07:56:56 -0500 From: "George, Wes" To: Randy Bush Date: Sat, 12 Nov 2011 07:57:17 -0500 Thread-Topic: various Thread-Index: AcyhKDI81Tfzw4xtTsmxm/84o1KYxQADkvwQ Message-ID: References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] various X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 12:56:58 -0000 > From: Randy Bush [mailto:randy@psg.com] > Sent: Saturday, November 12, 2011 5:45 AM > To: George, Wes > Cc: sidr wg list > Subject: Re: various > > > "However, signed updates received from BGPSec speakers outside of the > > confederation (i.e. those transiting the confederation ASes) MUST be > > passed to the other Member-ASes BGPSec speakers intact. > > nope. you could decide to strip toward one or more confed peers which > are not bgpsec capable. your routers, your decision, your policy. > don't go there. [WEG] there's no deciding. If the peers are not BGPSec capable, you're alre= ady required to strip towards that peer, no exception was made for confed p= eers. The only available policy decision is whether or not you want the inf= o carried across the confed to other BGPSec capable peers, so maybe make it= a SHOULD so that it's configurable, but I think it's incomplete as is. > > imiho, saying anything more is either adding unnecessary words at best > or opening up large complexity holes at worst. [WEG] yes, there's a fine line, but as I've said before, an operational con= siderations document is where some of these details and their associated pr= imrose paths have to be discussed, because you get into the shades of gray = world of operationalizing this stuff. We're not always going to be able to = consult you for a ruling on all of the things that you didn't say, and the = IETF has no Supreme Court to interpret the "founders" intentions for those = left behind. > > I figured it'd be clear from the above discussion > > and yet you want to me to go into unnecessary complications not > directly needed given my brutally specific statement? :) [WEG] Your brutally specific statement is so specific that it does not ment= ion the second case at all, because it's not about confeds. :-) Do you or do you not agree that on the transition between private ASN and p= ublic, if remove-private is configured, any signatures containing private A= SN must be removed even if the eBGP peer is BGPSec capable? Wes This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From danny@tcb.net Sat Nov 12 06:12:52 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FDB21F85FF for ; Sat, 12 Nov 2011 06:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.371 X-Spam-Level: X-Spam-Status: No, score=-102.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3A8XMB3F-Ab0 for ; Sat, 12 Nov 2011 06:12:52 -0800 (PST) Received: from uu.ops-netman.net (morrowc-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:36e::2]) by ietfa.amsl.com (Postfix) with ESMTP id EA5D221F848E for ; Sat, 12 Nov 2011 06:12:51 -0800 (PST) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [208.76.12.119]) by uu.ops-netman.net (Postfix) with ESMTP id A4CA81900DE; Sat, 12 Nov 2011 14:12:49 +0000 (UTC) Received: from [172.16.7.31] (unknown [122.147.35.3]) (Authenticated sender: danny@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 7EF88320093; Sat, 12 Nov 2011 14:12:47 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-9--797420164 From: Danny McPherson In-Reply-To: Date: Sat, 12 Nov 2011 09:12:43 -0500 Message-Id: <04E910F2-788C-47AB-BD55-D74209430CB4@tcb.net> References: <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com> <92AA1C8B-7CDB-406E-AA83-7C1BCD83CB69@ericsson.com> <32DF728C-A96A-435D-A54E-7626C2577F04@verisign.com> <7309FCBCAE981B43ABBE69B31C8D21391A44964302@EUSAACMS0701.eamcs.ericsson.se> , To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 14:12:52 -0000 --Apple-Mail-9--797420164 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 11, 2011, at 12:07 PM, Sriram, Kotikalapudi wrote: > So yes, I did consider the _prefix _ updates as is the case in BGPSEC = (not updates with packing in it). Sriram,=20 Yes, I saw this, and it is a useful datapoint. =20 I was looking for something more quantitative and closer to core=20 ISPs v. a single BGP feed at the "edge", as previously noted. Thanks,=20 -danny =20= --Apple-Mail-9--797420164 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
So yes, I did = consider the _prefix _ updates as is the case in BGPSEC (not updates = with packing in = it).

Sriram, 
Yes= , I saw this, and it is a useful datapoint. =  

I was looking for something more = quantitative and closer to core 
ISPs v. a single = BGP feed at the "edge", as = previously noted.

Thanks, 
-danny
 
= --Apple-Mail-9--797420164-- From danny@tcb.net Sat Nov 12 06:53:24 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C7521F8922 for ; Sat, 12 Nov 2011 06:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0sURYqazZdZ for ; Sat, 12 Nov 2011 06:53:24 -0800 (PST) Received: from uu.ops-netman.net (morrowc-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:36e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 772C221F8906 for ; Sat, 12 Nov 2011 06:53:24 -0800 (PST) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [208.76.12.119]) by uu.ops-netman.net (Postfix) with ESMTP id 1E1BD1901A3; Sat, 12 Nov 2011 14:53:24 +0000 (UTC) Received: from [172.16.7.31] (unknown [122.147.35.3]) (Authenticated sender: danny@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id E0E9D320245; Sat, 12 Nov 2011 14:53:19 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-15--794986012 From: Danny McPherson In-Reply-To: Date: Sat, 12 Nov 2011 09:53:17 -0500 Message-Id: References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com> To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] various X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 14:53:25 -0000 --Apple-Mail-15--794986012 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Nov 11, 2011, at 10:40 PM, Randy Bush wrote: > draft-ietf-sidr-bgpsec-ops-02 > > To prevent exposure of the internals of BGP Confederations [RFC5065], > a BGPsec speaker which is a Member-AS of a Confederation MUST NOT not > sign updates sent to another Member-AS of the same Confederation. Shouldn't supporting BGPSEC between Member-ASes of confederations be a requirement -- not simply ignored and out of scope? Particularly because of the manner in which they're used in many networks today for regional and topological policy and administrative boundaries? also, s/MUST NOT not/MUST NOT/ if it lives... -danny --Apple-Mail-15--794986012 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii In-Reply-To: References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] various X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 14:57:59 -0000 > Do you or do you not agree that on the transition between private ASN > and public, if remove-private is configured, any signatures containing > private ASN must be removed even if the eBGP peer is BGPSec capable? with the statement as is, if it is a private asn or a public asn, it is not signing. randy From danny@tcb.net Sat Nov 12 08:54:51 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2368F21F8713 for ; Sat, 12 Nov 2011 08:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqs3afWS+F8s for ; Sat, 12 Nov 2011 08:54:50 -0800 (PST) Received: from uu.ops-netman.net (morrowc-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:36e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8093621F86FF for ; Sat, 12 Nov 2011 08:54:50 -0800 (PST) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [208.76.12.119]) by uu.ops-netman.net (Postfix) with ESMTP id 2641A1900FE for ; Sat, 12 Nov 2011 16:54:50 +0000 (UTC) Received: from [172.16.7.31] (unknown [122.147.35.3]) (Authenticated sender: danny@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 828B6320245 for ; Sat, 12 Nov 2011 16:54:46 +0000 (UTC) From: Danny McPherson Content-Type: multipart/alternative; boundary=Apple-Mail-17--787699501 Date: Sat, 12 Nov 2011 11:54:44 -0500 Message-Id: To: sidr wg list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [sidr] Question about draft-ietf-sidr-pfx-validate-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 16:54:51 -0000 --Apple-Mail-17--787699501 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii My read of the current draft suggests that if there's a route generated = by the=20 local AS in BGP it could never have a "Valid" state, and by definition = would=20 either posses a "Not found" or "Invalid" state -- even though the local=20= AS may well have a "ROA" and reside in the mapping table as well(!). I do not believe the current text is Section 5 is sufficient to address = this case,=20 specifically with either this: "Considering invalid routes for BGP decision process is=20 a pure local policy matter and should be done with utmost care." or this: "In some cases (particularly when the selection algorithm is=20 influenced by the adjustment of a route property that is not=20 propagated into IBGP) it could be necessary for routing=20 correctness to propagate the validation state to the IBGP=20 peer. This can be accomplished on the sending side by setting=20 a community or extended community based on the validation=20 state, and on the receiving side by matching the (extended)=20 community and setting the validation state." I could think of a number of way to address this, but for there to exist = the=20 possibility that an internally generated prefix (for which a ROA may = well exists) could NEVER have a "Valid" state needs to be corrected. Also, S 4: s/to rest of the network/to the rest of the network/ Thanks,=20 -danny --Apple-Mail-17--787699501 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
either posses a "Not found" or = "Invalid" state -- even though the = local 
AS may well have a "ROA" and reside in = the mapping table as well(!).

I do not = believe the current text is Section 5 is sufficient to address this = case, 
specifically with either = this:

"Considering = invalid routes for BGP decision process = is 
a pure local policy = matter and should be done with utmost care."

or = this:

"In some cases = (particularly when the selection algorithm = is 
influenced by the = adjustment of a route property that is not 
propagated into IBGP) it could be necessary for = routing 
correctness = to propagate the validation state to the = IBGP 
peer. This can be = accomplished on the sending side by = setting 
a community or = extended community based on the = validation 
state, and on the = receiving side by matching the = (extended) 
community and = setting the validation state.

I could think of a number of = way to address this, but for there to exist = the 
possibility that an internally generated prefix (for = which a ROA may well exists)
could NEVER have a "Valid" state = needs to be corrected.

Also, S 4:  s/to rest of the network/to the rest of the = network/
X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EFC21F85AE for ; Sat, 12 Nov 2011 09:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7+PpKVNVKXH for ; Sat, 12 Nov 2011 09:29:07 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 01C9521F8540 for ; Sat, 12 Nov 2011 09:29:06 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so5325699bkb.31 for ; Sat, 12 Nov 2011 09:29:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Eud7Z8Ee5b0OzdrHiFYhC4pQcv46IEBSJ+YJZ5LIt20=; b=QwROyoYXgHckCFwlUel0zhKn8dZWtBKn2xfhjChT7nY4/AZJUyiSPlTbvTPS1iXcmu OXnRh+pU2iVjH5rx4oAvpB2wFtz1BNlRNgSmvtATy359N1xgzYx5+ihPoBE3R5QjRDLp A2eRatA2IMIXQfD0TCfGReLU6EYsG2UD6H8QU= MIME-Version: 1.0 Received: by 10.204.7.133 with SMTP id d5mr12907497bkd.64.1321118945917; Sat, 12 Nov 2011 09:29:05 -0800 (PST) Received: by 10.223.54.15 with HTTP; Sat, 12 Nov 2011 09:29:05 -0800 (PST) In-Reply-To: References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com> Date: Sat, 12 Nov 2011 12:29:05 -0500 Message-ID: From: Brian Dickson To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] various X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 17:29:07 -0000 In the case of confederations, and presuming BGPSEC is used among the confederation members, it should be the case that upon entry to the confederation, the "TO" ASN of the sender's signature is the AS Confederation Identifier, i.e. the externally visible ASN as which the confederation appears to its eBGP neighbors. The confederation will, in propagating an eBGP announcement, create an AS_CONFED_SEQUENCE, and corresponding signatures. Removing the signatures and removing the AS_CONFED_SEQUENCE, I believe, will preserve the signature validity, since the confederation member sending to a non-confederation member will add the AS Confederation Identifier (ASN) to the AS_SEQUENCE, and add its signature. The AS-path and signatures over such, will be valid/consistent. I.e., I think it "just works". So, I propose the following alternative text: To prevent exposure of the internals of BGP Confederations [RFC5065], and to comply with the requirement that the AS_SEQUENCE be identical to the sequence of ASNs from the Signature-Block, a BGPsec speaker which is a Member-AS of a Confederation MUST remove every Signature- Segment which corresponds to a unique ASN in the AS_CONFED_SEQUENCE prior to the AS_CONFED_SEQUENCE being removed from the AS_PATH, and prior to adding its own Signature-Segment to the Signature-Block. Or, wording to that effect. Brian On Fri, Nov 11, 2011 at 10:40 PM, Randy Bush wrote: > to two of your comments, in my unpublished edit buffers > > draft-ietf-sidr-bgpsec-ops-02 > > =A0 To prevent exposure of the internals of BGP Confederations [RFC5065], > =A0 a BGPsec speaker which is a Member-AS of a Confederation MUST NOT not > =A0 sign updates sent to another Member-AS of the same Confederation. > > draft-ietf-sidr-pfx-validate-04 > > =A0 An implementation MUST support 4 Octet AS Numbers, [RFC4893]. > > as our friendly blood-sucking vendors have said, the latter is thought > to be obvious. =A0but i figured to document it anyway, no harm. > > cool? > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From brian.peter.dickson@gmail.com Sat Nov 12 09:48:28 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D866021F86D0 for ; Sat, 12 Nov 2011 09:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32CXJqj2nRmj for ; Sat, 12 Nov 2011 09:48:28 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 018E521F867F for ; Sat, 12 Nov 2011 09:48:27 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so5339515bkb.31 for ; Sat, 12 Nov 2011 09:48:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zDmcXvcABJ0hsCiEwgHW238J7N4QuwqBxy8w8bwgN+k=; b=mrsIjHLA3Exnt9X2tN3ZyRcHmiF+/8S4mP2NWSYbrigkDkdiLlpPm+Xf1EuGJtFHHl fylfvF+zZg/D1DB+hBxRfn5H55XGTW6LH0Vs15FKj5BD1VQpR4zWp11OLS8LKZhqdkWR N3qovibI8afedC+63wauL1xsffVAL86tcqEpM= MIME-Version: 1.0 Received: by 10.205.138.17 with SMTP id iq17mr5072333bkc.118.1321120106985; Sat, 12 Nov 2011 09:48:26 -0800 (PST) Received: by 10.223.54.15 with HTTP; Sat, 12 Nov 2011 09:48:26 -0800 (PST) In-Reply-To: References: Date: Sat, 12 Nov 2011 12:48:26 -0500 Message-ID: From: Brian Dickson To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] Question about draft-ietf-sidr-pfx-validate-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 17:48:29 -0000 I think the current design of BGPsec as memorialized (love that word) in th= e draft-ietf-sidr-bgpsec-protocol would need to be tweaked to handle this. I also believe that the result of the proposed tweak, will be a cleaner des= ign which is easier to implement and verify, as well as not incurring significa= nt operational cost in terms of signatures. Local origination SHOULD occur within an AS on a permanent basis, and only the announcements from the actual originating router need to have unique signatures, regardless of whether they are iBGP or eBGP. (Crypto geeks might suggest adding a random "nonce" to make the signature a little harder to crack, since very little on the signature material will change over time - but that is another discussion.) Here is the tweak: Sequence of Octets to be Signed +---------------------------------------+ | Expire Time (8 octets) | +---------------------------------------+ | Origin AS Number (4 octets) | +---------------------------------------+ | Algorithm Suite Identifier (1 octet) | +---------------------------------------+ | NLRI Length (1 octet) | +---------------------------------------+ | NLRI Prefix (variable) | +---------------------------------------+ The "Target AS" and "pCount" need to be added, meaning the minimum number of signatures changes to "one origin" and "one propagation" signature. For iBGP within the originating AS, the signature would be "Target AS =3D=3D origin AS", and "pCount =3D=3D 0". For eBGP, it would be what you expect, "Target AS =3D=3D neighbor", "pCount= > 0". I think that's all that is needed, and the rest of the validation logic in the -protocol doc remain good, the -ops-reqs doc allows validation for local AS, and pfx-validate also wor= ks. Any detail or logic errors in the above can be attributed to not enough caffeine... The gist of the above should be solid enough, though. Brian On Sat, Nov 12, 2011 at 11:54 AM, Danny McPherson wrote: > > My read of the current draft suggests that if there's a route generated b= y > the > local AS=A0in BGP it could never have a "Valid" state, and by definition > would > either posses a "Not found" or "Invalid"=A0state --=A0even though the loc= al > AS may well have a "ROA" and reside in the=A0mapping table as well(!). > I do not believe the current text is Section 5 is sufficient to address t= his > case, > specifically with either this: > "Considering invalid routes for BGP decision process is > a pure local policy matter and should be done with utmost care." > or this: > "In some cases (particularly when the selection algorithm is > influenced by the adjustment of a route property that is not > propagated into IBGP) it could be necessary for routing > correctness to propagate the validation state to the IBGP > peer. This can be accomplished on the sending side by setting > a community or extended community based on the validation > state, and on the receiving side by matching the (extended) > community and setting the validation state." > I could think of a number of way to address this, but for there to exist > the > possibility that an internally generated prefix (for which a ROA may well > exists) > could NEVER have a "Valid" state needs to be corrected. > Also, S 4: =A0s/to rest of the network/to the rest of the network/ > Thanks, > -danny > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > From wesley.george@twcable.com Sat Nov 12 16:45:42 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1849521F8663 for ; Sat, 12 Nov 2011 16:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.365 X-Spam-Level: X-Spam-Status: No, score=-0.365 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doq-E4Xmyu0r for ; Sat, 12 Nov 2011 16:45:41 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6007821F8593 for ; Sat, 12 Nov 2011 16:45:40 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,501,1315195200"; d="scan'208";a="281456126" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 12 Nov 2011 19:40:39 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Sat, 12 Nov 2011 19:45:28 -0500 From: "George, Wes" To: Randy Bush Date: Sat, 12 Nov 2011 19:45:50 -0500 Thread-Topic: various Thread-Index: AcyhS3ks04MvHWQBRCmXTk/RaRECnwAUbO9Q Message-ID: References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] various X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 00:45:42 -0000 > From: Randy Bush [mailto:randy@psg.com] > Sent: Saturday, November 12, 2011 9:58 AM > To: George, Wes > Cc: sidr wg list > Subject: Re: various > > > Do you or do you not agree that on the transition between private ASN > > and public, if remove-private is configured, any signatures > containing > > private ASN must be removed even if the eBGP peer is BGPSec capable? > > with the statement as is, if it is a private asn or a public asn, it is > not signing. [WEG] sigh. Let me try one more time. This question is not about confederations so "the statement" is not applica= ble. Think just bog-standard, vanilla eBGP, with two BGPSec speakers, one of who= m is using a private ASN, announcing routes that must be carried to the DFZ= . Make more sense now as to why I'm making the distinction between private = and public ASN? Wes This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From randy@psg.com Sat Nov 12 17:21:39 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8BF21F8A7A for ; Sat, 12 Nov 2011 17:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxQyc5R9IOw4 for ; Sat, 12 Nov 2011 17:21:39 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id F20A521F8A6C for ; Sat, 12 Nov 2011 17:21:38 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RPOlM-000NHE-W1; Sun, 13 Nov 2011 01:21:37 +0000 Date: Sun, 13 Nov 2011 09:21:35 +0800 Message-ID: From: Randy Bush To: "George, Wes" In-Reply-To: References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] various X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 01:21:39 -0000 > Think just bog-standard, vanilla eBGP, with two BGPSec speakers, one > of whom is using a private ASN, announcing routes that must be carried > to the DFZ. Make more sense now as to why I'm making the distinction > between private and public ASN? yep. so we are on a completely separate, though a bit related, subject. got it. i need to think. needs of large 1918 clouds mean you just don't want to say 1918s don't sign. randy From brian.peter.dickson@gmail.com Sat Nov 12 17:29:51 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7D521F8ABE for ; Sat, 12 Nov 2011 17:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IHZBnwUCDdp for ; Sat, 12 Nov 2011 17:29:50 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C56F21F8541 for ; Sat, 12 Nov 2011 17:29:50 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so5637100bkb.31 for ; Sat, 12 Nov 2011 17:29:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=we5yp9NwbKtw7aPKCslXn9Lk4tpAhODVjchCk0Qmtz0=; b=gkxsjTL8weuYzNywJaD/OlWSY/33QYIP7SuNzN8Mwh0YheyHjxKmWz0v6KflPKcjXe uXOLrtMcxqdFgAfJJ74iAP7w2uxBEsjufz0k03u69aT+c+D4ERa6427gSghPeNjPKb1+ sCRo4DP62A89dRuIh5Mb/DBduFOAdEK01sfu4= MIME-Version: 1.0 Received: by 10.205.119.207 with SMTP id fv15mr13805959bkc.100.1321147789178; Sat, 12 Nov 2011 17:29:49 -0800 (PST) Received: by 10.223.54.15 with HTTP; Sat, 12 Nov 2011 17:29:49 -0800 (PST) In-Reply-To: References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com> Date: Sat, 12 Nov 2011 20:29:49 -0500 Message-ID: From: Brian Dickson To: "George, Wes" Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] various X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 01:29:51 -0000 On Sat, Nov 12, 2011 at 7:45 PM, George, Wes wrote: >> From: Randy Bush [mailto:randy@psg.com] >> Sent: Saturday, November 12, 2011 9:58 AM >> To: George, Wes >> Cc: sidr wg list >> Subject: Re: various >> >> > Do you or do you not agree that on the transition between private ASN >> > and public, if remove-private is configured, any signatures >> containing >> > private ASN must be removed even if the eBGP peer is BGPSec capable? >> >> with the statement as is, if it is a private asn or a public asn, it is >> not signing. > > [WEG] sigh. Let me try one more time. > This question is not about confederations so "the statement" is not applicable. > Think just bog-standard, vanilla eBGP, with two BGPSec speakers, one of whom is using a private ASN, announcing routes that must be carried to the DFZ. Make more sense now as to why I'm making the distinction between private and public ASN? Should we presume in your example, that the sequence is: private -> public -> public I.e. that there is no public ASN before the private ASN, and the route is originated by the private AS? I think the answer is something along the lines of, the private AS announces with its private AS as the origin, and the upstream public AS has its own trust anchor for assigning its instances of private AS ROA records. The public AS, to the outside world, appears to be the real originator, so the original signature is stripped completely, and a new signature block created using the public AS's "real" ROA info and signed as if it really was originated. Everything works beyond that. There really cannot be a transitive 1918->non-1918 signature path, because there cannot be 1918 ROAs with global significance, because of the AS's non-uniqueness. BGPsec from the announcer, transitively, can only be done with a public ASN. 4-byte ASNs are available now, expect demand to increase with BGPsec, IMHO. Brian From randy@psg.com Sat Nov 12 17:40:45 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A069411E808D for ; Sat, 12 Nov 2011 17:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnX0DX4QjzV5 for ; Sat, 12 Nov 2011 17:40:45 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 426BA11E808A for ; Sat, 12 Nov 2011 17:40:45 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RPP3s-000NKC-7T; Sun, 13 Nov 2011 01:40:44 +0000 Date: Sun, 13 Nov 2011 09:40:43 +0800 Message-ID: From: Randy Bush To: Brian Dickson In-Reply-To: References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] various X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 01:40:45 -0000 > BGPsec from the announcer, transitively, can only be done with a > public ASN. someone is gonna ask for a 1918 cloud and have their own trust anchor if it connects to the public network, yes, something is gonna have to get that private stuff off there. in a separate message, i think it was you who is proposing a protocol spec change/refinement. this thread is about the ops, not protocol, doc. i am hoping protocol geeks will have enough coffee soon that they can discuss. randy From pmohapat@cisco.com Sat Nov 12 23:36:41 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B5911E80B0 for ; Sat, 12 Nov 2011 23:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mILCqqn38ag8 for ; Sat, 12 Nov 2011 23:36:39 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8F84311E8093 for ; Sat, 12 Nov 2011 23:36:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pmohapat@cisco.com; l=1581; q=dns/txt; s=iport; t=1321169799; x=1322379399; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=dLyw3XEjg2mmLyPvC2x33q6Mc2bk7P/TbZNgg+sPdTc=; b=KYjHfjQPE9YXpUciN/K135p6SZy2HeurhpXxvr/aCnt+pPXfJ4OzlUXv oeu8hUBfWoa/zXNaTCX4r4t2FxKrEa9jLNnFSTH1dTWO8W2XaN/27gD7p PtXsQDOWyOrbW5a/bf3wKOcMbxrurW0eTDYWI5ixmI6T9ahj+i5LRjFKB M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABhyv06rRDoH/2dsb2JhbABCqi+BBYFpCQEBAQMBEgFmBQsLAwFCVwY1h2CYHQGdLIkcYwSIEIwekho X-IronPort-AV: E=Sophos;i="4.69,502,1315180800"; d="scan'208,217";a="13889346" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 13 Nov 2011 07:36:38 +0000 Received: from sjc-vpn4-362.cisco.com (sjc-vpn4-362.cisco.com [10.21.81.106]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAD7aclU024056; Sun, 13 Nov 2011 07:36:38 GMT Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: multipart/alternative; boundary=Apple-Mail-1--734786020 From: Pradosh Mohapatra In-Reply-To: Date: Sat, 12 Nov 2011 23:36:37 -0800 Message-Id: <8893BDFC-6BF9-4AB9-9C8B-FCF00F37A621@cisco.com> References: To: Danny McPherson X-Mailer: Apple Mail (2.1075.2) Cc: sidr wg list Subject: Re: [sidr] Question about draft-ietf-sidr-pfx-validate-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 07:36:41 -0000 --Apple-Mail-1--734786020 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes > My read of the current draft suggests that if there's a route > generated by the > local AS in BGP it could never have a "Valid" state, and by > definition would > either posses a "Not found" or "Invalid" state -- even though the > local > AS may well have a "ROA" and reside in the mapping table as well(!). Is there a need to compute validation state of an IBGP path? - Pradosh --Apple-Mail-1--734786020 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
My read of the current draft suggests that if there's a route generated by the 
local AS in BGP it could never have a "Valid" state, and by definition would 
either posses a "Not found" or "Invalid" state -- even though the local 
AS may well have a "ROA" and reside in the mapping table as well(!).


Is there a need to compute validation state of an IBGP path?

- Pradosh

--Apple-Mail-1--734786020-- From danny@tcb.net Sun Nov 13 00:05:16 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B8621F8AD1 for ; Sun, 13 Nov 2011 00:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDbAFeRIH24d for ; Sun, 13 Nov 2011 00:05:15 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 63F1521F8AD2 for ; Sun, 13 Nov 2011 00:05:15 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 0717D268063; Sun, 13 Nov 2011 01:05:15 -0700 (MST) Received: from dhcp-1267.meeting.ietf.org (dhcp-1267.meeting.ietf.org [130.129.18.103]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sun, 13 Nov 2011 01:05:14 -0700 (MST) (envelope-from danny@tcb.net) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <8893BDFC-6BF9-4AB9-9C8B-FCF00F37A621@cisco.com> Date: Sun, 13 Nov 2011 03:04:57 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <8893BDFC-6BF9-4AB9-9C8B-FCF00F37A621@cisco.com> To: Pradosh Mohapatra X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] Question about draft-ietf-sidr-pfx-validate-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 08:05:16 -0000 On Nov 13, 2011, at 2:36 AM, Pradosh Mohapatra wrote: > Is there a need to compute validation state of an IBGP path? I need some way to convey in iBGP it's preference relative to other BGP-learned paths - how do I do that today under this architecture, where if it were considered under the current algorithm it may well be labeled "Invalid", even if a mapping exists for the local AS and prefix in question? -danny From jgs@juniper.net Sun Nov 13 00:18:28 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D34111E8081 for ; Sun, 13 Nov 2011 00:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY5BMn93Rkgs for ; Sun, 13 Nov 2011 00:18:28 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id CFF0E21F8B0B for ; Sun, 13 Nov 2011 00:18:27 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTr99UYMNqfuB5TuWyN0SAouwe8XaT/vP@postini.com; Sun, 13 Nov 2011 00:18:28 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Sun, 13 Nov 2011 00:12:23 -0800 From: John Scudder To: Brian Dickson Date: Sun, 13 Nov 2011 00:12:22 -0800 Thread-Topic: [sidr] Question about draft-ietf-sidr-pfx-validate-03 Thread-Index: Acyh2/iXYPGEVq+2S92voo/0gPTNcQ== Message-ID: <50D11ABB-8AFB-48EB-B0CE-753EEA39D539@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] Question about draft-ietf-sidr-pfx-validate-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 08:18:28 -0000 Brian, Danny is talking about pfx-validate, which is not the same as BGPSEC. --John On Nov 13, 2011, at 1:48 AM, Brian Dickson wrote: > I think the current design of BGPsec as memorialized (love that word) in = the > draft-ietf-sidr-bgpsec-protocol would need to be tweaked to handle this. >=20 > I also believe that the result of the proposed tweak, will be a cleaner d= esign > which is easier to implement and verify, as well as not incurring signifi= cant > operational cost in terms of signatures. >=20 > Local origination SHOULD occur within an AS on a permanent > basis, and only the announcements from the actual originating router need > to have unique signatures, regardless of whether they are iBGP or eBGP. >=20 > (Crypto geeks might suggest adding a random "nonce" to make the signature > a little harder to crack, since very little on the signature material > will change > over time - but that is another discussion.) >=20 > Here is the tweak: >=20 > Sequence of Octets to be Signed > +---------------------------------------+ > | Expire Time (8 octets) | > +---------------------------------------+ > | Origin AS Number (4 octets) | > +---------------------------------------+ > | Algorithm Suite Identifier (1 octet) | > +---------------------------------------+ > | NLRI Length (1 octet) | > +---------------------------------------+ > | NLRI Prefix (variable) | > +---------------------------------------+ >=20 > The "Target AS" and "pCount" need to be added, meaning the minimum > number of signatures > changes to "one origin" and "one propagation" signature. >=20 > For iBGP within the originating AS, the signature would be "Target AS > =3D=3D origin AS", and "pCount =3D=3D 0". >=20 > For eBGP, it would be what you expect, "Target AS =3D=3D neighbor", "pCou= nt > 0". >=20 > I think that's all that is needed, and the rest of the validation > logic in the -protocol doc remain good, > the -ops-reqs doc allows validation for local AS, and pfx-validate also w= orks. >=20 > Any detail or logic errors in the above can be attributed to not > enough caffeine... The gist of the above > should be solid enough, though. >=20 > Brian >=20 > On Sat, Nov 12, 2011 at 11:54 AM, Danny McPherson wrote: >>=20 >> My read of the current draft suggests that if there's a route generated = by >> the >> local AS in BGP it could never have a "Valid" state, and by definition >> would >> either posses a "Not found" or "Invalid" state -- even though the local >> AS may well have a "ROA" and reside in the mapping table as well(!). >> I do not believe the current text is Section 5 is sufficient to address = this >> case, >> specifically with either this: >> "Considering invalid routes for BGP decision process is >> a pure local policy matter and should be done with utmost care." >> or this: >> "In some cases (particularly when the selection algorithm is >> influenced by the adjustment of a route property that is not >> propagated into IBGP) it could be necessary for routing >> correctness to propagate the validation state to the IBGP >> peer. This can be accomplished on the sending side by setting >> a community or extended community based on the validation >> state, and on the receiving side by matching the (extended) >> community and setting the validation state." >> I could think of a number of way to address this, but for there to exist >> the >> possibility that an internally generated prefix (for which a ROA may wel= l >> exists) >> could NEVER have a "Valid" state needs to be corrected. >> Also, S 4: s/to rest of the network/to the rest of the network/ >> Thanks, >> -danny >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 >>=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From jgs@juniper.net Sun Nov 13 00:21:39 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56E221F8B0D for ; Sun, 13 Nov 2011 00:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWWzW+WU3TpF for ; Sun, 13 Nov 2011 00:21:39 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 235F721F8B0C for ; Sun, 13 Nov 2011 00:21:39 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTr9+EqTHLzi8uTkPw6+NvxlivKXqp0kC@postini.com; Sun, 13 Nov 2011 00:21:39 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Sun, 13 Nov 2011 00:17:07 -0800 From: John Scudder To: Danny McPherson Date: Sun, 13 Nov 2011 00:17:06 -0800 Thread-Topic: [sidr] Question about draft-ietf-sidr-pfx-validate-03 Thread-Index: Acyh3KG1WY3zhIjYSrWMy2LRzLmIbQ== Message-ID: <258A421C-BC96-4076-8DDA-A9C87045151A@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] Question about draft-ietf-sidr-pfx-validate-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 08:21:40 -0000 Danny, IMO the way to handle this is observe that all routes have a validity state= attribute and that it needs to be settable in policy. I believe the draft= already says this (I will check though) and so it provides the necessary m= inimum toolset needed to apply a given state to local routes. It might be = worth saying something about what state a route should take by default, whi= ch I'm pretty sure we don't do now. (If done this might need to be broken = down into several cases, e.g. EBGP vs. IBGP vs. locally originated.) --John On Nov 13, 2011, at 12:54 AM, Danny McPherson wrote: >=20 > My read of the current draft suggests that if there's a route generated b= y the=20 > local AS in BGP it could never have a "Valid" state, and by definition wo= uld=20 > either posses a "Not found" or "Invalid" state -- even though the local=20 > AS may well have a "ROA" and reside in the mapping table as well(!). >=20 > I do not believe the current text is Section 5 is sufficient to address t= his case,=20 > specifically with either this: >=20 > "Considering invalid routes for BGP decision process is=20 > a pure local policy matter and should be done with utmost care." >=20 > or this: >=20 > "In some cases (particularly when the selection algorithm is=20 > influenced by the adjustment of a route property that is not=20 > propagated into IBGP) it could be necessary for routing=20 > correctness to propagate the validation state to the IBGP=20 > peer. This can be accomplished on the sending side by setting=20 > a community or extended community based on the validation=20 > state, and on the receiving side by matching the (extended)=20 > community and setting the validation state." >=20 > I could think of a number of way to address this, but for there to exist = the=20 > possibility that an internally generated prefix (for which a ROA may well= exists) > could NEVER have a "Valid" state needs to be corrected. >=20 > Also, S 4: s/to rest of the network/to the rest of the network/ >=20 > Thanks,=20 >=20 > -danny >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From danny@tcb.net Sun Nov 13 03:37:54 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E835321F8B3F for ; Sun, 13 Nov 2011 03:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BKOofMHYSPh for ; Sun, 13 Nov 2011 03:37:54 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 8441D21F8B2E for ; Sun, 13 Nov 2011 03:37:54 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 5770D268063; Sun, 13 Nov 2011 04:37:54 -0700 (MST) Received: from [172.16.7.31] (122.147.35.3 [122.147.35.3]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sun, 13 Nov 2011 04:37:54 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=122.147.35.3; client-port=43452; syn-fingerprint=65535:44:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <258A421C-BC96-4076-8DDA-A9C87045151A@juniper.net> Date: Sun, 13 Nov 2011 06:37:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <225C5FF4-7B60-4DC6-A13E-B496C434C20A@tcb.net> References: <258A421C-BC96-4076-8DDA-A9C87045151A@juniper.net> To: John Scudder X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] Question about draft-ietf-sidr-pfx-validate-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 11:37:55 -0000 On Nov 13, 2011, at 3:17 AM, John Scudder wrote: > IMO the way to handle this is observe that all routes have a validity = state attribute and that it needs to be settable in policy. I believe = the draft already says this (I will check though) and so it provides the = necessary minimum toolset needed to apply a given state to local routes. = It might be worth saying something about what state a route should take = by default, which I'm pretty sure we don't do now. (If done this might = need to be broken down into several cases, e.g. EBGP vs. IBGP vs. = locally originated.) Agreed, thanks John,=20 -danny= From pmohapat@cisco.com Sun Nov 13 09:23:42 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A987E21F84C1 for ; Sun, 13 Nov 2011 09:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMnWI73p4rRn for ; Sun, 13 Nov 2011 09:23:42 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2093121F84A0 for ; Sun, 13 Nov 2011 09:23:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pmohapat@cisco.com; l=511; q=dns/txt; s=iport; t=1321205023; x=1322414623; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=e/kzBNZ7EBXU7M6R9VNDiBJ2tBekxvznFBAwGB/Frko=; b=LMXi9bgvg0CfDodgjJPwCxXp/8glXXvwMZAgWKl/KjiYLwQyvxnGE0Yc 2ASz0Lk+Lfm2Xj7CnVEf5eCPeENLPuZbls4DKmf6DIt8VMt8FGr9A2ik3 Px9kGcULgKy1zuCrUQ37Imb9TvJuf8OnuPOe1XDXlWhXV4EL1HI80tAVF o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAF78v06rRDoJ/2dsb2JhbABCqXuBBYFyAQEBAwESASUCPwULCxI0SQ4GNYdgl0IBnTaJHGMEiBCMHpIa X-IronPort-AV: E=Sophos;i="4.69,503,1315180800"; d="scan'208";a="13980054" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 13 Nov 2011 17:23:43 +0000 Received: from sjc-vpn7-850.cisco.com (sjc-vpn7-850.cisco.com [10.21.147.82]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pADHNhJK023785; Sun, 13 Nov 2011 17:23:43 GMT Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Pradosh Mohapatra In-Reply-To: Date: Sun, 13 Nov 2011 09:23:43 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <8893BDFC-6BF9-4AB9-9C8B-FCF00F37A621@cisco.com> To: Danny McPherson X-Mailer: Apple Mail (2.1075.2) Cc: sidr wg list Subject: Re: [sidr] Question about draft-ietf-sidr-pfx-validate-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 17:23:42 -0000 > I need some way to convey in iBGP it's preference relative to other > BGP-learned paths - how do I do that today under this architecture, > where if it were considered under the current algorithm it may well > be labeled "Invalid", even if a mapping exists for the local AS and > prefix in question? Implementations mark it as valid today (unless the validation state extcomm says otherwise). Re. John's reply, it probably makes sense to clarify in the doc. Thanks for the comment. - Pradosh From brian.peter.dickson@gmail.com Sun Nov 13 12:38:36 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17FE21F8801 for ; Sun, 13 Nov 2011 12:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrjGSilhKS98 for ; Sun, 13 Nov 2011 12:38:35 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id BA27B21F87E2 for ; Sun, 13 Nov 2011 12:38:34 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so6376220bkb.31 for ; Sun, 13 Nov 2011 12:38:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7IAuIAOwdo/OuPT8eBjfMGAPipTm5HZWCsytSLjYQi8=; b=JNjgRWJXW4OrOSXc3tVoYT2247dxzbOQUtVe+sCepWhgQX4vC+1DM9h/sGOsW+Mvy9 MBD7wZ0ENXBh83CAjhlyxft/n03fIFPBPxJuwut8a32mjuDutGgHAz3jTNHofhL8yR7L iKVzReOub7LW0M4HpJGebesvvsHFMXvQFApuo= MIME-Version: 1.0 Received: by 10.204.130.90 with SMTP id r26mr4489985bks.46.1321216712422; Sun, 13 Nov 2011 12:38:32 -0800 (PST) Received: by 10.223.54.15 with HTTP; Sun, 13 Nov 2011 12:38:32 -0800 (PST) In-Reply-To: <50D11ABB-8AFB-48EB-B0CE-753EEA39D539@juniper.net> References: <50D11ABB-8AFB-48EB-B0CE-753EEA39D539@juniper.net> Date: Sun, 13 Nov 2011 15:38:32 -0500 Message-ID: From: Brian Dickson To: John Scudder Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] Question about draft-ietf-sidr-pfx-validate-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 20:38:36 -0000 Correct, yes, I understand. My point is, that because of the inter-relatedness of the various SIDR documents, and because presumably the bgpsec-protocol document is not set in stone, the issues raised in other documents (in SIDR) can be considered as creating requirements to the protocol document. As in, by making changes to the protocol (and necessarily the protocol draft), the issues elsewhere can be designed away and made moot. It is taking a holistic approach to the set of SIDR documents rather than documenting around an existing pre-standards bgpsec implementation. I humbly suggest that the authors of the other documents take a closer look at things I suggest, and perhaps voice them as concerns in the -protocol discussion, as relates to the overall design and in particular their own documents. Some see the glass as half-full, some as half-empty. I see the glass as too big. :-) Brian On Sun, Nov 13, 2011 at 3:12 AM, John Scudder wrote: > Brian, > > Danny is talking about pfx-validate, which is not the same as BGPSEC. > > --John > > On Nov 13, 2011, at 1:48 AM, Brian Dickson wrote: > >> I think the current design of BGPsec as memorialized (love that word) in= the >> draft-ietf-sidr-bgpsec-protocol would need to be tweaked to handle this. >> >> I also believe that the result of the proposed tweak, will be a cleaner = design >> which is easier to implement and verify, as well as not incurring signif= icant >> operational cost in terms of signatures. >> >> Local origination SHOULD occur within an AS on a permanent >> basis, and only the announcements from the actual originating router nee= d >> to have unique signatures, regardless of whether they are iBGP or eBGP. >> >> (Crypto geeks might suggest adding a random "nonce" to make the signatur= e >> a little harder to crack, since very little on the signature material >> will change >> over time - but that is another discussion.) >> >> Here is the tweak: >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sequence of Octets to be Sign= ed >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +---------------------------------------= + >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Expire Time (8 octets) =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0| >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +---------------------------------------= + >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Origin AS Number (4 octets) =A0 =A0 = =A0 =A0 =A0 | >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +---------------------------------------= + >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Algorithm Suite Identifier =A0(1 octet= ) | >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +---------------------------------------= + >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | NLRI Length =A0(1 octet) =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +---------------------------------------= + >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | NLRI Prefix =A0(variable) =A0 =A0 =A0 = =A0 =A0 =A0 =A0 | >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +---------------------------------------= + >> >> The "Target AS" and "pCount" need to be added, meaning the minimum >> number of signatures >> changes to "one origin" and "one propagation" signature. >> >> For iBGP within the originating AS, the signature would be "Target AS >> =3D=3D origin AS", and "pCount =3D=3D 0". >> >> For eBGP, it would be what you expect, "Target AS =3D=3D neighbor", "pCo= unt > 0". >> >> I think that's all that is needed, and the rest of the validation >> logic in the -protocol doc remain good, >> the -ops-reqs doc allows validation for local AS, and pfx-validate also = works. >> >> Any detail or logic errors in the above can be attributed to not >> enough caffeine... The gist of the above >> should be solid enough, though. >> >> Brian >> >> On Sat, Nov 12, 2011 at 11:54 AM, Danny McPherson wrote: >>> >>> My read of the current draft suggests that if there's a route generated= by >>> the >>> local AS in BGP it could never have a "Valid" state, and by definition >>> would >>> either posses a "Not found" or "Invalid" state -- even though the local >>> AS may well have a "ROA" and reside in the mapping table as well(!). >>> I do not believe the current text is Section 5 is sufficient to address= this >>> case, >>> specifically with either this: >>> "Considering invalid routes for BGP decision process is >>> a pure local policy matter and should be done with utmost care." >>> or this: >>> "In some cases (particularly when the selection algorithm is >>> influenced by the adjustment of a route property that is not >>> propagated into IBGP) it could be necessary for routing >>> correctness to propagate the validation state to the IBGP >>> peer. This can be accomplished on the sending side by setting >>> a community or extended community based on the validation >>> state, and on the receiving side by matching the (extended) >>> community and setting the validation state." >>> I could think of a number of way to address this, but for there to exis= t >>> the >>> possibility that an internally generated prefix (for which a ROA may we= ll >>> exists) >>> could NEVER have a "Valid" state needs to be corrected. >>> Also, S 4: =A0s/to rest of the network/to the rest of the network/ >>> Thanks, >>> -danny >>> >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>> >>> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > From brian.peter.dickson@gmail.com Sun Nov 13 12:42:42 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F88521F8AA8 for ; Sun, 13 Nov 2011 12:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1U0+qLvNN7v for ; Sun, 13 Nov 2011 12:42:41 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6589721F8AE6 for ; Sun, 13 Nov 2011 12:42:41 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so6379515bkb.31 for ; Sun, 13 Nov 2011 12:42:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=esb2IZV3xRIxVhQWRuM4PXJtVMlQJO2/ov85ATdXfhg=; b=pjlzjAC8riVS3PdrCQSYm1+GLc2hMr9m+cOtUVuaLjjdsBRWPNMJL0cLwN6TFozABO 3/QfGMejcGbfOsXagQ+EVhBcEvPz/p++B41fIM6gUhayf9br5ieTdsI49a4qXa+6fTtZ WyDcOrATJAt1hr7936/2HbeqqSy0uhbUAcNiY= MIME-Version: 1.0 Received: by 10.204.133.216 with SMTP id g24mr8946123bkt.82.1321216958482; Sun, 13 Nov 2011 12:42:38 -0800 (PST) Received: by 10.223.54.15 with HTTP; Sun, 13 Nov 2011 12:42:38 -0800 (PST) In-Reply-To: References: <20111031193803.30761.81234.idtracker@ietfa.amsl.com> <4EB02586.5010101@bbn.com> Date: Sun, 13 Nov 2011 15:42:38 -0500 Message-ID: From: Brian Dickson To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] various X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 20:42:42 -0000 On Sat, Nov 12, 2011 at 8:40 PM, Randy Bush wrote: > in a separate message, i think it was > you who is proposing a protocol spec change/refinement. =A0this thread is > about the ops, not protocol, doc. =A0i am hoping protocol geeks will have > enough coffee soon that they can discuss. Yep - while it is correct to say, "protocol changes may impact the ops doc"= , it isn't terribly useful without specifics. I was providing specifics. Hope= fully some of the folks discussing the ops doc(s) will convey the issues with the protocol folks. IMHO, some aspects of ops need to inform the protocol design, rather than having the protocol docs simply memorialize someone's experimental design. Brian From brian.peter.dickson@gmail.com Sun Nov 13 14:14:23 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD35721F8AAF for ; Sun, 13 Nov 2011 14:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.954 X-Spam-Level: X-Spam-Status: No, score=-2.954 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9ANFYovfZF1 for ; Sun, 13 Nov 2011 14:14:22 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5FB21F8A97 for ; Sun, 13 Nov 2011 14:14:21 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so6445372bkb.31 for ; Sun, 13 Nov 2011 14:14:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=hswp9iXf28P7X74L0LPBYbuo8L9LmepxkMUOBbz4adM=; b=usPOojTkvKj+t8NiuL5S+gFMsOqMaEv0WeUxQv9eplmAmf+MMMKh+0lOfwBordFr4A hEfKddjfQ2WBHyznH0u/bAWbTD0ram4hjxPvYw4+Exa7Qy6gKpzEthjCxWnYcDSYrx7i DwOReyaesmIm6G2HLB9sXIfaUHzvUGyYKPFss= MIME-Version: 1.0 Received: by 10.204.136.211 with SMTP id s19mr9698608bkt.28.1321222461065; Sun, 13 Nov 2011 14:14:21 -0800 (PST) Received: by 10.223.54.15 with HTTP; Sun, 13 Nov 2011 14:14:20 -0800 (PST) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F6025FEE@Hermes.columbia.ads.sparta.com> Date: Sun, 13 Nov 2011 17:14:20 -0500 Message-ID: From: Brian Dickson To: "sidr@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 22:14:24 -0000 Dear SIDR-WG, Since my original message was pretty long and detailed, and it does not appear anyone has made it through it yet, let me try to summarize the main issues with which it is concerned. The current proposal focuses on ending support for Algorithm A. IMHO, it does so at the expense of the process by which support for Algorithm B is introduced. What I'm suggesting is, that instead of tying the two together, each be handled separately. And I'm suggesting that providing a path for early and widespread (but not necessarily universal) adoption of "B", without regard to ending support for "A", is more important than ending "A". (Obviously, starting "B" and ending "A" can't be entirely independent, since removing A before B is supported, would be illogical in the extreme.) It may be premature, as well, to suggest the overall strategy before getting significant input from ICANN/IANA folks who will be prime on the trust anchor and root certificates of the system, and operational processes and strategies for making changes to them. ICANN/IANA's experience doing similar things in signing the DNSSEC root, and the processes they used, may better inform the "agility" document. NB: The most difficult thing about ending "Algorithm A" is stopping it being used. This can be done independently, by having CAs delete certs using "A", or by having RPs have a "knob" to say, "don't use Algorithm 'A'". I suggest both should be done. It's dead easy, IMHO. The difficulty in introducing "Algorithm B" is much more substantial. It involves new code for CAs, new code for RPs (multiple vendors, multiple hardware platforms, many code streams, etc.). There are interoperability requirements in three directions at least (CA-CA, rtr-rtr, and rtr-CA). It also pretty much requires non-lab experimentation, which means having certs issued which involve at least one signature using "B". It also means that experimentation may involve announcing BGPsec prefixes using such certs, before all RPs understand "B". There might be a place for describing use of an "alternative trust anchor" to enable testing using production systems, without directly impacting production certificates. New CA code supporting "B" (and "A") could be deployed, and a chain of trust using a different trust anchor and a mix of "A" and "B" certs (either/or at each delegation point), would allow for exercising the code while maintaining the "real" cert chain, e.g. as a final test before actually replacing "A"-signed certs with "B"-signed certs. Trust anchors can be established at any CA, and while the root "CA" is one place one would expect this to be done, it isn't the only place it is possible (and advisable) to do so. Putting this into the phases is important, specifically so everyone knows this activity is expected, and that all implementers are prepared (in their implementations) to be sensible in their code. Having those phases have flexibility in them, and having them coordinated with feedback loops built in, is a much smarter way to go than having deadlines. I would rather see full top-to-bottom support for all-B certs, than worry about some certs that still have one or more "A" signatures in them. Earlier transition to "B" at the root is possible if flexible strategies are employed. Providing RPs with "no A" knobs makes the CA-signing side of ending "A" cert signatures much less of a security-critical issue. The scalability issue (avoiding exponential growth in number of published certs) means every cert should be signed with only one algorithm. This results in a single major requirement - RPs who want BGPsec to work, must be able to handle Algorithm "B" certs, before the root is signed with "B". This is _very_ different from requiring top-down deployment. Coordinating this is very important, but IMHO, does not require two "parallel" chains of certs (all "A", and all "B" respectively). This would be a "flag day", or close enough to it to be ill advised. Having RPs having code that supports "B", with knobs for "allow-B" and "allow-A", means RPs will have sufficient control to limit exposure to security issues or operational issues, specific to "A" or "B". It also allows deployment of new code without exposure to premature use of prefixes used for testing. It also means a final wave of "B" enablement, followed by a "B" root-signing, can be coordinated without the kind of risk that a no-fall-back scenario (which the current document requires) at all. A problem with a B-signed root can be fixed by having the A-signed root re-deployed, either by a new A signature or by rolling back the old signatures. The original email below, goes into some of the "how" and "why" to demonstrate the feasibility of this approach, and suggestions for how this can be incorporated into a newer version of the "agility" document. (If this were easy, my emails would be much shorter.) Brian On Wed, Nov 9, 2011 at 4:44 PM, Brian Dickson wrote: > Rather than respond, point-by-point, I will top-reply, and try to > clear this up in a structured manner. > > First, from the perspective of normative references: > - most of the main SIDR documents reference each other, both > generally, and in specific places. > -- e.g. -rpki-algs-05 refers to -arch, -cp, -res-certs and -signed-object > -- e.g. -cp explicitly delegates algorithm specification to -rpki-algs > -- e.g. -res-certs section 9, in addition to referring to -cp, clearly > indicates that versions of itself and -cp need to be re-issued in > lock-step > -- e.g. Changing (by updating/replacing) the RFC for -rpki-algs, would > actually require issuing new versions of -cp, -res-certs, and > -rpki-algs, as a "document set". > > I believe I would be accurate in saying, one of the primary purposes > of having an algorithm-agility doc, is to document what would need to > happen if a new set of algorithms to be published. And the scope of > the agility needs to include interaction between the RPKI system and > the consumers of that data, the RPs. > > Let us stay with one "current" CP. > > Again, the presumption is: one -cp doc, one -res-certs doc, one > -rpki-algs doc; and the agility doc describing the necessary state > changes to go from one controlling, unified set of docs, to another > controlling, unified set of docs. > > It's is all about the content of the "rpki-algs" document; everything > (the top-down and exponential growth issues in particular) hinge on > that. > > [terminology] > Alg.suite =3D { algorithms } > Let A denote Alg.Suite "A" (upper case means suite) > let a denote algorithm (or alg-pair) "a" (lower case means algorithm) > A example of the above would be: > X =3D { n p q } > [end terminology] > > [example cases] > A =3D { a } > B =3D { b } > C =3D { a b } =A0 =A0(Algorithm suite C, includes algorithms "a" and "b") > [end example cases] > > Note the following (Venn diagram) results: > A ^ B =3D { } > A ^ C =3D { a } =3D A > C ^ B =3D { b } =3D B > A v B =3D { a b } =3D C > A v C =3D { a b } =3D C > C v B =3D { a b } =3D C > > The current algorithm-agility document presumes that an algorithm > update will always be of the form "A -> B". > It is because of the fact that A ^ B =3D {}, that the duplicate certs > problem arises, which gives rise to the exponential problem, which > leads to top-down. > With more than one suite, it becomes necessary to have multiple certs. > A cert is only valid within one suite. > > If you consider suites A and C, note that a cert valid under A, is > _also_ valid under C - it does not require new key date; it may need > to re-issue. > > If, instead, the updates were done by two successive, albeit > technically independent, updates, "A -> C", followed by "C -> B", the > problem goes away. > > The timelines involved for "A -> C" would look like: > =A0 Process for RPKI CAs: > > =A0 =A0 Phase 0 =A0 Phase 1 =A0 Phase 2 =A0 Phase 3 > =A0 -----------x--------x--------x---------- > =A0 =A0 ^ =A0 =A0 =A0 =A0^ =A0 =A0 =A0 =A0^ =A0 =A0 =A0 =A0^ > =A0 =A0 | =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0| > =A0 =A0(1) =A0 =A0 =A0(2a) =A0=A0=A0 (3) =A0 =A0 =A0(4) > > =A0 Process for RPKI RPs: > > =A0=A0=A0 Phase 0 =A0 =A0=A0 Phase 1 > =A0 --------------x-----x------------------- > =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 ^ > =A0 =A0 | =A0 =A0 =A0 =A0 =A0 | =A0 =A0 | > =A0 =A0(1) =A0 =A0 =A0 =A0 (2b)=A0 (3) > > =A0 (1) RPKI's algorithm document updated. > =A0 (2a) CA Ready Algorithm C Date (all CAs can accept algorithms in set > C, "a" or "b" specifically) > =A0 (2b) RP Ready Algorithm C Date (all RPs can validate algorithms in > set C, "a" or "b" specifically) > =A0 (3) CA/RP Set Algorithm C Date (all RPs and CAs now are ready - on > or after later of 2a/2b) > =A0 (4) CA Go Algorithm C Date (any given CA can now _choose_ to switch > from using "a" to using "b") > > The mechanics on re-issuing certificates are clear. In the last > paragraph of "sidr-arch", section 4.2: > > =A0 If a CA certificate is reissued with the same public key, it should > =A0 not be necessary to reissue (with an updated AIA URI) all > =A0 certificates signed by the certificate being reissued. Therefore, a > =A0 certification authority SHOULD use a persistent URI naming scheme for > =A0 issued certificates. That is, reissued certificates should use the > =A0 same publication point as previously issued certificates having the > =A0 same subject and public key, and should overwrite such certificates. > > So, if we presume that Algorithm suite C allows the choice of two > algorithms, then a CA can switch from > one algorithm to the other by (a) re-requesting its own CA cert using > the PoP of its new public key, > which is the public key for algorithm "b"; and (b) reissuing all of > its certificates using the new key. > > Every certificate is signed by exactly one algorithm, and there is no > problem with the algorithm being > either "a" or "b". RPs understand both "a" and "b" before this > happens. There is no requirement for > keeping more than one certificate, so there is no exponential problem. > (Each cert identifies algs by OID.) > > And furthermore, the re-issuing is done unilaterally by each CA, > meaning each CA can choose to do so > (or not!) any time after the "go" date. This can happen at any time, > in any order, independently. > > Note very well: The most important aspect of this is, that _each_ CA, > in this model, has the ability to roll back > unilaterally, since both algorithms are valid. There are no timing or > hierarchy dependencies to this. > > In fact, the only time there is a need for ensuring all CAs have done > so, is when there is a "C -> B" update. > > All that needs to happen for "C -> B" is for every CA to have > re-issued their certs using suite B (alg "b" only), > by that date, and to stop accepting requests with public keys of alg > "a" at that time. > > Again, at no time in this transition are duplicate certs needed > (neither 2 nor 3, no exponentiation). > And the re-issuing is done unilaterally by each CA, with no top-down > requirement. > > You are right on this issue: > - The RPs and PoP rules definitely mean that only one rpki-algs > document and one CP can be "current" (phase 0) at any time, globally. > > However, I disagree that that single algorithm suite, needs to contain > only _one_ pair of algorithms. The wisdom of the WG, > and of expert advice from the PKIX folks, should inform the contents > of the rpki-algs, and conceivably this could contain > more than one hash/keying algorithm pair. E.g. RSA/SHA 384 and 512, > and also an EC algorithm, for a choice of 3 algs. > As long as the alg choices are justified and mainstream, I don't see > any problem with more than one. > > One other point about "C -> B" transitions: the transition avoids the > top-down (or exponential) issue, if C ^ B =3D B, > i.e. if C is strictly a superset of B. However, nothing in this rule > places restrictions on the sizes of C or B. > It is conceivable that more than one algorithm be retired during such > a transition. > It is also entirely possible that the post-retirement set of > algorithms be larger than one. > E.g C =3D { a b c d e }, B =3D { b c e }. > This creates more flexibility in terms of WG work, and more perceived > stability operationally. > CAs are then free to choose from multiple algorithms. > Thus, zero day risks on one active algorithm don't require IETF > response, as CAs can trivially switch to another active algorithm. > > I'd even go so far as suggesting pre-publishing "document sets" (-cp, > -rpki-algs, -res-certs) for multiple future alg sets, > in advance, well in advance, to give implementers and operators the > longest possible lead time. > > Respectfully, > > Brian > > P.S. The multiple CP and =A0CPS goes away in the above - so long as the > rpki-algs supports multiple algs. > > On Wed, Nov 9, 2011 at 1:42 PM, Stephen Kent wrote: >> At 1:27 AM -0500 11/8/11, Brian Dickson wrote: >> >> ... >> >> I do not support adoption of this document in its current form. >> >> The main reasons have to do with fundamental aspects which at a high >> >> level have been addressed by my colleagues, >> >> so, this is a Verisign critique, provided by you, Eric, and Danny? >> >> Here's why: >> - everybody is a CA. Both the "root" of the INR tree (ICANN/IANA), >> plus the RIRs, etc., down to the publishers of EE certs. >> >> yes, essentially every actor in the RPKI is both a CA and an RP. >> >> - each CA publishes its policy via a CPS (it's a SHOULD, but >> functionally a MUST for RPs to be able to understand what a CA >> publishes.) >> >> small ISPs and orgs that have address space probably will not bother wit= h a >> CPS, which is why it is a SHOULD, not a MUST. In a typical PKI context, = a >> CPS primarily benefits the subjects to whom certs are issued; RPs also a= re >> potential CPS consumers.=A0 In the RPKI, a "keaf" CA issues certs to its= elf, >> so a CPS is not of much interest for the first class of consumers. In th= e >> RPLI one does not get to shop around to choose a CA, so RPs don't need m= uch >> from a CPS. >> >> >> - Each CPS specifies the OID of the corresponding CP >> >> there is just one CP. not clear form your statement if thatr ws clear. >> >> - Each CP refers to the corresponding policy for algorithms >> >> there is only one policy (CP) for the RPKI, and it specifies algs via a >> reference to an alg spec. so, I am not sure what you have in mind here. >> >> - Algorithms themselves have OIDs and are referenced as such in certs >> >> yes. >> >> - Every cert also specifies the OID of the CP itself (which embodies >> >> the rules for allowed algorithms) >> >> yes. >> >> So while the first revision of the CP insists on only one algorithm >> for pub/private keys, and one algorithm for hashes, it explicitly >> calls out that these are expected to change. >> >> yes. >> >> In changing allowed algorithms, it can reasonably be inferred that CPs >> could be issued which increase the _number_ of allowed algoriths of >> both types beyond one. >> >> there is only one CP. >> >> And similarly, the methodology demonstrated by key rollover has local >> >> scope. There is no requirement that children do anything at all when a >> parent executes a key roll. _This is by design_. >> >> yes, this is by design, but is irrelevant to the the alg transition desi= gn, >> which has global impact (on all RPs). >> >> So the analogous high-level design for agility SHOULD be as follows: >> - new CP documents may be published, with new OIDs >> >> as I mentioned above, there is one CP for the RPKI. When you suggest mul= tile >> CPs, are you thinking of them on a per CA basis, or RPKI-wide? >> >> - ONLY when a CA with a given CPS decides to change CP does that CA >> need to execute a locally-significant key+alg roll >> >> see question above. also, unlike key roll, an alg roll affects ALL RPs, >> which is why the analogy between the two procedures is bad. Also, note m= y >> 'reply to Brian re the top-dowen deployment model that the Wg adopted, t= o >> avoid >> exponential growth in the repository system. >> >> - The CA would issue new certs with the new CP which itself lists >> >> additional algorithms >> >> ibid. >> >> - The same procedure would be executed in multiple phases - issue new >> child certs published under the old main cert; move them to the new >> cert, rewriting/overwriting in the same location >> >> ibid. >> >> This could be handled gracefully by having two CPs - one CP having the >> additional algorithm(s), and subsequently another CP with the new but >> >> minus the old. >> >> not graceful re repository growth, and impact on RPs. >> >> This mechanism could be used to introduce new algorithms without >> requiring retiring specific old algorithms. The two actions - adding >> and removing - are in fact independent, beyond the requirement that >> there be at least one algorithm (which goes without saying, really). >> The only other requirement is that the issued certs have algorithms >> consistent with the specified CP (OID) attached to the cert. >> >> there needs to be one alg that ALL RPs can deal with at all times.=A0 Al= so, >> unlike key roll, when a CA wants to have a new cert with a public key >> using a new alg, its parent MUST be able to support that alg, because of >> the PoP requirement. >> >> I may be completely off the mark, but this would seem to be much more >> in line with the whole manner in which algorithms, policies, resource >> objects, etc., have been separated out and linked by normative >> reference. >> >> I do not agree. >> >> Perhaps we could get Geoff Huston to comment on my interpretation of >> the CP/CPS/alg interaction and explicit/implicit rules? >> Is it intended that CAs have a uniform hierarchy using exactly one >> algorithm set, or is it intended that each CA be able to specify (via >> >> CPS + CP)=A0 the set of algorithms it supports, with the initial CP >> document being the minimum acceptable algorithm set? >> >> This text suggests that you believe there is on CP per CA, vs. a >> system-wide CP. The architecture is the latter.=A0 Also, while I respect >> Goeff, why is your question directed to him? I am a co-author of the CP, >> the arch, and the key roll and the alg roll docs :-). >> Steve > From warren@kumari.net Sun Nov 13 14:54:25 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A0421F8AE6 for ; Sun, 13 Nov 2011 14:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.901 X-Spam-Level: X-Spam-Status: No, score=-105.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3SlsSB1YEE7 for ; Sun, 13 Nov 2011 14:54:24 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id BB88121F8ABD for ; Sun, 13 Nov 2011 14:54:24 -0800 (PST) Received: from my.router (dhcp-46bc.meeting.ietf.org [130.129.70.188]) by vimes.kumari.net (Postfix) with ESMTPSA id AAE651B40424 for ; Sun, 13 Nov 2011 17:54:23 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Nov 2011 06:54:19 +0800 Message-Id: <49768DDB-C24F-40F4-BD8E-B7CFF0B56375@kumari.net> To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [sidr] Please take a look at proposed IDR doc, draft-wkumari-idr-as0-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 22:54:25 -0000 Hi all, Over in IDR there is currently a call for adoption of = draft-wkumari-idr-as0-01 -- this draft belongs in IDR (it clarifies a = minor point in BGP docs), but one of hte main reasons for the drafts = existence is to support SIDR features. So far there not been much discussion on the call for adoption, so I'm = asking that SIDR folk who also follow IDR please take a minute to look = at the draft and express an opinion (on the IDR list=85) The 10,000 foot view of the draft is that it specifies that routes that = have AS0 as the origin (or in the path should be dropped[0)]. This is to prevent folk from hijacking space if we use AS0 as the origin = for address resources that a not currently in use -- like done in = I-D.ietf-sidr-iana-objects and elsewhere. For ease of finding the draft: = http://tools.ietf.org/html/draft-wkumari-idr-as0-01 -- it is really = short (4 pages, 3 of them mostly boilerplate) and simply a codification = / clarification of existing code, so it shouldn't take much time to = review.=20 The deadline for discussion is tomorrow's IDR meeting (November 15 2011, = 09:00 Taipei time). W=20 [0]: technically treated as a withdrawal.= From weiler@watson.org Sun Nov 13 15:10:50 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820CA21F8B25 for ; Sun, 13 Nov 2011 15:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYnEcDVxx8xm for ; Sun, 13 Nov 2011 15:10:50 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5A621F8B12 for ; Sun, 13 Nov 2011 15:10:48 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id pADNAlD1059307 for ; Sun, 13 Nov 2011 18:10:47 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id pADNAkXL059303 for ; Sun, 13 Nov 2011 18:10:47 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sun, 13 Nov 2011 18:10:46 -0500 (EST) From: Samuel Weiler To: sidr@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Sun, 13 Nov 2011 18:10:47 -0500 (EST) Subject: Re: [sidr] sidr move to Tue 1300 (was Re: possible wg time slot change) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 23:10:50 -0000 Resending this to make sure that it pops to the top of everyone's mailbox now that we have our paper agendas in hand. On Tue, 8 Nov 2011, Sandra Murphy wrote: > PKIX did cancel their 1300 Tue time slot yesterday. The routing ADs approved > moving the sidr wg to that time slot and requested the secretariat to make > the move. (I presume that makes it a done deal.) > > This all came up after the final agenda was printed and the move is not yet > reflected on the agenda page. So you might need to keep track on your own. > > --Sandy, speaking as wg chair > > On Fri, 28 Oct 2011, Sandra Murphy wrote: > >> To accommodate our Tech Advisor, we are investigating a sidr move to an >> early day in the week. >> >> There's a good possibility that we'll move to Mon afternoon in place of >> cuss or opsec. That would mean that an hour of the agenda would still be >> on Fri. >> >> There's a remote possibility that we'll move the entire agenda to Tue at >> 1pm if another wg cancels. >> >> Moving pends approval of respective ADs etc. >> >> But thought you might like notice. >> >> --Sandy >> >> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > From randy@psg.com Sun Nov 13 15:42:00 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7119121F8444 for ; Sun, 13 Nov 2011 15:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwyzDfuDjVTo for ; Sun, 13 Nov 2011 15:42:00 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8A321F842E for ; Sun, 13 Nov 2011 15:42:00 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RPjgS-000PCh-OM; Sun, 13 Nov 2011 23:41:57 +0000 Date: Mon, 14 Nov 2011 07:41:55 +0800 Message-ID: From: Randy Bush To: Pradosh Mohapatra In-Reply-To: References: <8893BDFC-6BF9-4AB9-9C8B-FCF00F37A621@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] Question about draft-ietf-sidr-pfx-validate-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 23:42:00 -0000 >> I need some way to convey in iBGP it's preference relative to other >> BGP-learned paths - how do I do that today under this architecture, >> where if it were considered under the current algorithm it may well >> be labeled "Invalid", even if a mapping exists for the local AS and >> prefix in question? > > Implementations mark it as valid today (unless the validation state > extcomm says otherwise). Re. John's reply, it probably makes sense to > clarify in the doc. Thanks for the comment. workshop folk have asked to have intra-as generated routes marked. it is not clear to me that this would be bad. randy From kent@bbn.com Sun Nov 13 18:18:21 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901A111E80DF for ; Sun, 13 Nov 2011 18:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.521 X-Spam-Level: X-Spam-Status: No, score=-106.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFoPNAPiuM2t for ; Sun, 13 Nov 2011 18:18:20 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 211A611E8087 for ; Sun, 13 Nov 2011 18:18:20 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:45178 helo=[130.129.18.170]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RPm7l-0004Oi-KP; Sun, 13 Nov 2011 21:18:19 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> <3F1388E3-A694-42C9-AE2F-F12BF15DC86F@verisign.com> Date: Sun, 13 Nov 2011 21:16:48 -0500 To: Eric Osterweil From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-890885399==_ma============" Cc: "sidr@ietf.org list" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 02:18:21 -0000 --============_-890885399==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Eric, In response to your message from last week. Some candidate text dealing with the timeline document in section 2: An additional document, the algorithm transition=20 timeline will be published as a BCP (?) to define=20 the timeline for the algorithm suite transition.=20 It will defines dates for the phase transitions,=20 consistent with the descriptions provided in=20 Section 4. It is RECOMMENDED that the timeline=20 document be developed by the entities that act as=20 CAs, RPs, and repository operators in the RPKI,=20 e.g., IANA, Internet Registries, and network=20 operators. It is also RECOMMENDED that the=20 timeline document describe procedures to track=20 the progress of the transition and to amend the=20 timeline, e.g., if problems arise in implementing=20 later phases of the transition. You raised a question about the implications for=20 CAs that do not transition to the new algorithm=20 suite, motivated by the last paragraph of section=20 11. You posited that "=8A the implication is that=20 if any CA doesn't keep up (so to speak) they are=20 considered invalid and therefore would be=20 un-routable?" That's not quite accurate. At the=20 end of Phase 4 the Internet resources of any CAs=20 that have not made the transition will be treated=20 the same as resources that have not been=20 protected via RPKI certificates and ROAs.=20 Participation in the RPKI is voluntary, so there=20 may always been unprotected resources in the=20 public Internet. These are not un-routable, but=20 they are subject to hijacking. You suggested that we codify how the community=20 should deal with problems that motivate delaying=20 a phase transition. We're not writing the=20 timeline document now, but the text at the=20 beginning of this message is an effort to make=20 sure such considerations are addressed in that=20 document. You suggested that we add text, for each phase,=20 saying "=8A what to do if its success requirements=20 are not met (exceptions, error legs, etc)."=20 Here's my proposed initial text to address your=20 question: Phase 0 is the start of the process, when a new=20 algorithm suite has been selected and the=20 timeline published. The only problem I envision=20 that might arise at this stage, prior to Phase 1,=20 is a discovery of a problem that makes Suite B=20 unacceptable. If this situation arises, the=20 algorithm document will have to be reissued with=20 a new Suite B, and the timeline document will be=20 reissued. Phase 1 requires all CAs to be able to issue=20 certificates under Suite B. If a problem arises=20 that makes this infeasible for a substantial=20 number of CAs, the timeline document can be=20 reissued, pushing back this date, and dates for=20 subsequent milestones. CAs that are capable of=20 issuing Suite B certificates may continue to do=20 so, if requested by their child CAs. Since this=20 phase does not require any RPs to process signed=20 objects under Suite B, and since Suite B product=20 SHOULD be stored at independent publication=20 points, there is no adverse impact on RPs. Phase 2 requires that CAs MUST publish all signed=20 products under Suite B, as well as Suite A, and=20 RP MAY be prepared to validate these products=20 using Suite B. If a problem arises that makes=20 this infeasible for a substantial number of CAs,=20 the timeline document can be reissued, pushing=20 back this date and dates for subsequent=20 milestones. (Since the processing requirement for=20 RPs here is MAY, if RPs have problems with Suite=20 B products this does not require pushing back the=20 Phase 2 milestone, but it does motivate delaying=20 the start of Phase 3.) CAs that are capable of=20 publishing products under Suite B may continue to=20 do so. Phase 2, like Phase 1, does not require=20 any RPs to process signed objects under Suite B,=20 and since Suite B product SHOULD be stored at=20 independent publication points, there is no=20 adverse impact on RPs. Phase 3 requires that RPs MUST be able to process=20 Suite B signed products, and RPs are encouraged=20 to validate signed products using Suite B.=20 However, each RP is required to be able to fall=20 back to using the Suite A product if the Suite B=20 product set cannot be validated. As Section 4.6=20 notes, there are no CA behavior changes at this=20 phase, so there is no requirement for CA=20 rollback. If a substantial number of RPs are=20 unable to process product sets signed with Suite=20 B, this Phase could be delayed, and subsequent=20 milestones pushed back. There is no rollback=20 required here, as there is no change in CA=20 behavior. Phase 4 begins the phase out of Suite A. At this=20 phase products sets signed under the old=20 algorithm suite may begin to disappear, i.e., CAs=20 MAY choose to not publish them anymore. This=20 phase should be delayed if it is determined that=20 many RPs are not capable of processing the new=20 algorithm suite. There is no rollback required if=20 this phase is delayed. However, CAs should be=20 reminded to not remove old algorithm suite A=20 product sets if this phase is delayed. Section 4.8 describes EOL for the old algorithm=20 suite, i.e., it kills off all support for the old=20 algorithm suite. It is described as a return to=20 Phase 0. If we wait until Phase 0, then it may be=20 a very, very long time before the old Suite A is=20 killed off. We may want to revisit this, i.e., if=20 we want to kill off the old algorithm suite=20 sooner. Your last comment deals with the question of=20 top-down vs. laissez faire algorithm transition.=20 I think your comment is that we cannot mandate=20 adherence to the transition process and timeline.=20 Use of the RPKI, both the issuance of signed=20 products and their consumption, is optional. So,=20 no, we cannot mandate adherence to this timeline.=20 But, we can establish a transition process and=20 timeline for all CAs and RPs that chose to follow=20 it. The goal in establishing the process and=20 timeline is to minimize the cost to the=20 community, as a whole, for the transition.=20 Externalization of cost is the appropriate term=20 here (from economics perspective) to describe=20 what happens if one were to adopt the laissez=20 faire approach. (Chaos might be an alterative=20 term :-)) =46irst, not that a CA cannot unilaterally decide=20 to transition to a new algorithm. There is a=20 requirement that the issuer of its certificate is=20 prepared to accept a certificate request under=20 the new algorithm suite (because of the PoP=20 requirement). The exponential growth arises if we have Suite A=20 and B product sets at each tier. If we allow CAs=20 to "do their own thing," there is the potential=20 for four combinations: - a Suite A certificate issued under Suite A - a Suite A certificate issued under Suite B - a Suite B certificate issued under Suite A - a Suite B certificate issued under Suite B If we allow all of these combinations, which may=20 be needed to allow RPs to process signed products=20 during the transition, then each tier has this=20 potential 4-way branching, to accommodate RPs at=20 different stages of algorithm capability. If you=20 want more details, I suggest reviewing the slides=20 from the SIDR WG meeting that I believe I cited=20 previously. When Geoff Huston initially noted=20 this problem, I disagreed, and it was not until I=20 started to write the spec that I realized what he=20 meant. To avoid more flame wars, I will duck your=20 question about my views on DNSSEC and=20 accommodation of different algorithm suites :-). Steve --============_-890885399==_ma============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03
Eric,

In response to your message from last week.

Some candidate text dealing with the timeline document in section 2:

An additional document, the algorithm transition timeline will be published as a BCP (?) to define the timeline for the algorithm suite transition. It will defines dates for the phase transitions, consistent with the descriptions provided in Section 4. It is RECOMMENDED that the timeline document be developed by the entities that act as CAs, RPs, and repository operators in the RPKI, e.g., IANA, Internet Registries, and network operators. It is also RECOMMENDED that the timeline document describe procedures to track the progress of the transition and to amend the timeline, e.g., if problems arise in implementing later phases of the transition.


You raised a question about the implications for CAs that do not transition to the new algorithm suite, motivated by the last paragraph of section 11. You posited that "=8A the implication is that if any CA doesn't keep up (so to speak) they are considered invalid and therefore would be un-routable?" That's not quite accurate. At the end of Phase 4 the Internet resources of any CAs that have not made the transition will be treated the same as resources that have not been protected via RPKI certificates and ROAs. Participation in the RPKI is voluntary, so there may always been unprotected resources in the public Internet. These are not un-routable, but they are subject to hijacking.

You suggested that we codify how the community should deal with problems that motivate delaying a phase transition. We're not writing the timeline document now, but the text at the beginning of this message is an effort to make sure such considerations are addressed in that document.

You suggested that we add text, for each phase, saying "=8A what to do if its success requirements are not met (exceptions, error legs, etc)." Here's my proposed initial text to address your question:

Phase 0 is the start of the process, when a new algorithm suite has been selected and the timeline published. The only problem I envision that might arise at this stage, prior to Phase 1, is a discovery of a problem that makes Suite B unacceptable. If this situation arises, the algorithm document will have to be reissued with a new Suite B, and the timeline document will be reissued.

Phase 1 requires all CAs to be able to issue certificates under Suite B. If a problem arises that makes this infeasible for a substantial number of CAs, the timeline document can be reissued, pushing back this date, and dates for subsequent milestones. CAs that are capable of issuing Suite B certificates may continue to do so, if requested by their child CAs. Since this phase does not require any RPs to process signed objects under Suite B, and since Suite B product SHOULD be stored at independent publication points, there is no adverse impact on RPs.

Phase 2 requires that CAs MUST publish all signed products under Suite B, as well as Suite A, and RP MAY be prepared to validate these products using Suite B. If a problem arises that makes this infeasible for a substantial number of CAs, the timeline document can be reissued, pushing back this date and dates for subsequent milestones. (Since the processing requirement for RPs here is  MAY, if RPs have problems with Suite B products this does not require pushing back the Phase 2 milestone, but it does motivate delaying the start of Phase 3.) CAs that are capable of publishing products under Suite B may continue to do so. Phase  2, like Phase 1, does not require any RPs to process signed objects under Suite B, and since Suite B product SHOULD be stored at independent publication points, there is no adverse impact on RPs.

Phase 3 requires that RPs MUST be able to process Suite B signed products, and RPs are encouraged to validate signed products using Suite B. However, each RP is required to be able to fall back to using the Suite A product if the Suite B product set cannot be validated. As Section 4.6 notes, there are no CA behavior changes at this phase, so there is no requirement for CA rollback. If a substantial number of RPs are unable to process product sets signed with Suite B, this Phase could be delayed, and subsequent milestones pushed back. There is no rollback required here, as there is no change in CA behavior.

Phase 4 begins the phase out of Suite A. At this phase products sets signed under the old algorithm suite may begin to disappear, i.e., CAs MAY choose to not publish them anymore. This phase should be delayed if it is determined that many RPs are not capable of processing the new algorithm suite. There is no rollback required if this phase is delayed. However, CAs should be reminded to not remove old  algorithm suite A product sets if this phase is delayed.

Section 4.8 describes EOL for the old algorithm suite, i.e., it kills off all support for the old algorithm suite. It is described as a return to Phase 0. If we wait until Phase 0, then it may be a very, very long time before the old Suite A is killed off. We may want to revisit this, i.e., if we want to kill off the old algorithm suite sooner.
Your last comment deals with the question of top-down vs. laissez faire algorithm transition. I think your comment is that we cannot mandate adherence to the transition process and timeline. Use of the RPKI, both the issuance of signed products and their consumption, is optional. So, no, we cannot mandate adherence to this timeline. But, we can establish a transition  process and timeline for all CAs and RPs that chose to follow it. The goal in establishing the process and timeline is to minimize the cost to the community, as a whole, for the transition. Externalization of cost is the appropriate term here (from economics perspective) to describe what happens if one were to adopt the laissez faire approach. (Chaos might be an alterative term :-))

=46irst, not that a CA cannot unilaterally decide to transition to a new algorithm. There is a requirement that the issuer of its certificate is prepared to accept a certificate request under the new algorithm suite (because of the PoP requirement).

The exponential growth arises if we have Suite A and B product sets at each tier. If we allow CAs to "do their own thing," there is the potential for four combinations:
- a Suite A certificate issued under Suite A
- a Suite A certificate issued under Suite B
- a Suite B certificate issued under Suite A
- a Suite B certificate issued under Suite B

If we allow all of these combinations, which may be needed to allow RPs to process signed products during the transition, then each tier has this potential 4-way branching, to accommodate RPs at different stages of algorithm capability. If you want more details, I suggest reviewing the slides from the SIDR WG meeting that I believe I cited previously. When Geoff Huston initially noted this problem, I disagreed, and it was not until I started to write the spec that I realized what he meant.
To avoid more flame wars, I will duck your question about my views on DNSSEC and accommodation of different algorithm suites :-).

Steve
--============_-890885399==_ma============-- From brian.peter.dickson@gmail.com Sun Nov 13 19:25:47 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7994A1F0C47 for ; Sun, 13 Nov 2011 19:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jk-IWCV6UCb4 for ; Sun, 13 Nov 2011 19:25:46 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2CB1F0CC1 for ; Sun, 13 Nov 2011 19:25:46 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so6661565bkb.31 for ; Sun, 13 Nov 2011 19:25:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ebk4px+AM48aCvWWPO1wEaJ+CZtPSoZFsTDg+XUMak4=; b=IPW+vCftD5I+7ypZ6ZrdIGSkcmIj0yzJocq/2WBAOkB5m0M3vkmHLmeG1TQCUJOhFl IMyPyzfdT0Xp2R5UcCN2OCv40/2lCDma2YguFGzLjW1/usujCXMEL+IijsF2Q8Nts+pE wWlVe0ad0kQYWE8/oUP/K1NBALiMQK7rAxuVw= MIME-Version: 1.0 Received: by 10.204.130.90 with SMTP id r26mr5416257bks.46.1321241143932; Sun, 13 Nov 2011 19:25:43 -0800 (PST) Received: by 10.223.54.15 with HTTP; Sun, 13 Nov 2011 19:25:43 -0800 (PST) In-Reply-To: References: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> <3F1388E3-A694-42C9-AE2F-F12BF15DC86F@verisign.com> Date: Sun, 13 Nov 2011 22:25:43 -0500 Message-ID: From: Brian Dickson To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org list" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 03:25:47 -0000 On Sun, Nov 13, 2011 at 9:16 PM, Stephen Kent wrote: > You suggested that we codify how the community should deal with problems > that motivate delaying a phase transition. We're not writing the timeline > document now, but the text at the beginning of this message is an effort to > make sure such considerations are addressed in that document. When you say "timeline document", do you mean "timeline for specific implementation of the phases in this document"? I ask because the algorithm-agility sure looks like a timeline document. The main concerns rise from the content and order of the phases, and their consequences. > Phase 0 is the start of the process, when a new algorithm suite has been > selected and the timeline published. > > Phase 1 requires all CAs to be able to issue certificates under Suite B. > > Phase 2 requires that CAs MUST publish all signed products under Suite B, as > well as Suite A, and RP MAY be prepared to validate these products using > Suite B. > > Phase 3 requires that RPs MUST be able to process Suite B signed products, > and RPs are encouraged to validate signed products using Suite B. > > Phase 4 begins the phase out of Suite A. > > > First, not that a CA cannot unilaterally decide to transition to a new > algorithm. There is a requirement that the issuer of its certificate is > prepared to accept a certificate request under the new algorithm suite > (because of the PoP requirement). This statement is entirely predicated on having Phase 2, as it is currently defined, after Phase 1 (CAs ready for receiving B) and before Phase 3 (when RPs are able to validate using B). I don't see what this step in this order, buys us, or even that it is necessary at all. Let's take a look at what happens after Phase 3: - RPs speak "B". - CAs can process "B". Is this not the (only!) pre-condition required for supporting any of the four combinations? > If we allow CAs to "do their own thing," there is the potential for > four combinations: > - a Suite A certificate issued under Suite A > - a Suite A certificate issued under Suite B > - a Suite B certificate issued under Suite A > - a Suite B certificate issued under Suite B > > The exponential growth arises if we have Suite A and B product sets at each > tier. I don't see the requirement to support more than one certificate (ie of more than one of the four types.) After Phase 1 and Phase 3, but ignoring your Phase 2, we know: - RPs speak "B" - CAs can accept requests with PoP == "B". A certificate of any of the four types can be issued by any CA, and validated by any RP. Which type depends only on the CA (signature alg) and the subordinate CA (key/PoP type). There is no exponential growth _unless_ multiple cert types for each cert are maintained, which I disagree with as being a requirement _at_all_. I do not see a reason to need more than one certificate, regardless of which of the four types it is. So, the only possible danger with allowing any CA to switch to "B" whenever it wants, is that should that occur before the end of phase 3 (when all RPs speak "B"), all subordinate certificates will be at risk for not validating with those RPs who are not "B"-ready. However, experimentation during the early deployment stages, almost demands for this ability, and that there would be the expectation of such failure by those using (or more accurately, testing) code prior to widespread adoption. Earliest work would be done using leaf "B" certs, and early-deployment code. Gradually additional levels of testing (B-B and B-B-B), until enough traction in deployment in CA code and RP code has occurred. This eventually culminate with "B" root transition. Deploying code without this incremental testing, and then expecting it to "just work", suggests a lack of experience and familiarity with the deployment of new operational code features in a multi-vendor environment on the Internet... _Especially_ if there is no compelling reason. Can you show me what compels the maintenance of both types of certificates, and a "fall-back-to-A" logic? We have another term for "fall-back-to-foo" - it's called a "downgrade attack". I'll withdraw my objection if anyone can make a truly compelling case using only the assumptions above - Phase 1 and Phase 3, followed by widespread issuance of production "B" certs, on a timeline entirely determined by local CA decisions. Brian From christopher.morrow@gmail.com Sun Nov 13 20:03:56 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A1B11E81C8 for ; Sun, 13 Nov 2011 20:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.535 X-Spam-Level: X-Spam-Status: No, score=-103.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yz0dtM3VT9td for ; Sun, 13 Nov 2011 20:03:55 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF7111E8095 for ; Sun, 13 Nov 2011 20:03:55 -0800 (PST) Received: by iaeo4 with SMTP id o4so8739044iae.31 for ; Sun, 13 Nov 2011 20:03:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=DHApfHlocN9NMmI8jLlHOliUutuMPpQR/uZ0WppV5GE=; b=vooTrVgoY38c1r/3i1QGlqYQqX/BL9XXxcIuGKugBUmBJLPfa8C8yXmn10RVxyFjJ5 6GErE2fsgFcz6qEWm0Saj4oIUZwR0ivBEbB2QLPXO8wujSWvd6q6bogyIfo1rpcjPa7C RXeRtaP+Khu0NI+Yrelmu0yjBzXPD2sb7K2Co= MIME-Version: 1.0 Received: by 10.50.36.161 with SMTP id r1mr21486665igj.37.1321243435294; Sun, 13 Nov 2011 20:03:55 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Sun, 13 Nov 2011 20:03:55 -0800 (PST) In-Reply-To: References: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> <6054A2B1-40D3-49E6-8972-946D426E830B@castlepoint.net> Date: Sun, 13 Nov 2011 23:03:55 -0500 X-Google-Sender-Auth: 6T_VCsycbeKjTSrHPnkRpB2hY74 Message-ID: From: Christopher Morrow To: "George, Wes" Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 04:03:56 -0000 Checking back on this... I see that Randy had rev'd the document since this last conversation-set ... Danny has 2 editorial changes and 1 'large' comment... I don't yet see any feedback on those, but the previous set of comments/requests are taken care of to the original peoples' satsifaction? I suspect some feedback to Danny will come soonish, but can we close out the other set of requests? -chris From randy@psg.com Sun Nov 13 20:30:19 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BC611E8088 for ; Sun, 13 Nov 2011 20:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGOGD7J53h1v for ; Sun, 13 Nov 2011 20:30:19 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id F154D11E8080 for ; Sun, 13 Nov 2011 20:30:18 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RPoBS-0000Jp-Su; Mon, 14 Nov 2011 04:30:15 +0000 Date: Mon, 14 Nov 2011 12:30:13 +0800 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> <6054A2B1-40D3-49E6-8972-946D426E830B@castlepoint.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 04:30:19 -0000 > Checking back on this... I see that Randy had rev'd the document since > this last conversation-set ... Danny has 2 editorial changes and 1 > 'large' comment... I don't yet see any feedback on those, but the > previous set of comments/requests are taken care of to the original > peoples' satsifaction? > > I suspect some feedback to Danny will come soonish, but can we close > out the other set of requests? one of danny's ed comments confuses me. NotFound is a keyword. danny's substantial comment, re marking of stuff originated internally within one's own AS, is o in pfx-validate, as it is protocol, o has been raised by ops in workshops, and o is being madly discussed offline as the router implementors have some problems with side-effects of marking them i have been holding -13 in my edit buffer for some weeks, tweaking as clues filtered in from mailing list. i can drop it now, as i presume the flood gates have opened, or hold it until later in the week. randy From kent@bbn.com Sun Nov 13 21:24:41 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1941F0C6D for ; Sun, 13 Nov 2011 21:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxW7oDdDAUuR for ; Sun, 13 Nov 2011 21:24:40 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 994C81F0C4F for ; Sun, 13 Nov 2011 21:24:40 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:54142 helo=[130.129.18.170]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RPp26-0005K1-8c; Mon, 14 Nov 2011 00:24:38 -0500 Mime-Version: 1.0 Message-Id: Date: Mon, 14 Nov 2011 00:21:06 -0500 To: eosterweil@verisign.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: [sidr] addendum X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 05:24:41 -0000 Eric, I forgot to address an issue that you mentioned in a previous message, and that relates to the alg agility doc. The alg spec for the RPKI is separate from the CP, precisely so that we could change the algs without changing the CP. So, when the alg spec is replaced to introduce the next set of algs, we do not plan to re-issue the CP. As a result, the cert policy OID will not change as a side effect of the alg transition. I discussed this assumption re OID stability with several PKI experts today, and they agreed that there is no need to change the policy OID. i mention this because I recall that a previous message touched on this question, and I realize that the alg agility doc failed to mention this. The next rev will make this explicit. Steve From shane@castlepoint.net Sun Nov 13 21:36:48 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6157121F8C97 for ; Sun, 13 Nov 2011 21:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZkwjsMlBXe9 for ; Sun, 13 Nov 2011 21:36:47 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 4F33E11E8177 for ; Sun, 13 Nov 2011 21:36:47 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id BE9B6268063; Sun, 13 Nov 2011 22:36:46 -0700 (MST) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sun, 13 Nov 2011 22:36:46 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=64521; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Shane Amante In-Reply-To: Date: Mon, 14 Nov 2011 13:36:41 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> <6054A2B1-40D3-49E6-8972-946D426E830B@castlepoint.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1251.1) Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 05:36:48 -0000 Hi Chris, Randy, On Nov 14, 2011, at 12:03 PM, Christopher Morrow wrote: > Checking back on this... I see that Randy had rev'd the document since > this last conversation-set ... Danny has 2 editorial changes and 1 > 'large' comment... I don't yet see any feedback on those, but the > previous set of comments/requests are taken care of to the original > peoples' satsifaction? >=20 > I suspect some feedback to Danny will come soonish, but can we close > out the other set of requests? I don't recall seeing a response to the last e-mail I sent, nor do I see = anything in the latest -12, related to this doc: http://www.ietf.org/mail-archive/web/sidr/current/msg03475.html -shane= From eosterweil@verisign.com Sun Nov 13 22:05:45 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCD211E8208 for ; Sun, 13 Nov 2011 22:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oY1qNz4iM6Q for ; Sun, 13 Nov 2011 22:05:44 -0800 (PST) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id C616611E8207 for ; Sun, 13 Nov 2011 22:05:43 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKTsCvspJxDIuqbh0Z0va1MwEmusj5c/tL@postini.com; Sun, 13 Nov 2011 22:05:43 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id pAE65cJQ028517; Mon, 14 Nov 2011 01:05:38 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.69]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Nov 2011 01:05:35 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Eric Osterweil In-Reply-To: Date: Mon, 14 Nov 2011 14:05:32 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> <3F1388E3-A694-42C9-AE2F-F12BF15DC86F@verisign.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 14 Nov 2011 06:05:35.0438 (UTC) FILETIME=[6CB1B6E0:01CCA293] Cc: "sidr@ietf.org list" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 06:05:45 -0000 Hey Steve, Thanks for the response. I commented below: On Nov 14, 2011, at 10:16 AM, Stephen Kent wrote: > Eric, >=20 > In response to your message from last week. >=20 > Some candidate text dealing with the timeline document in section 2: >=20 > An additional document, the algorithm transition timeline will be = published as a BCP (?) to define the timeline for the algorithm suite = transition. It will defines dates for the phase transitions, consistent = with the descriptions provided in Section 4. It is RECOMMENDED that the = timeline document be developed by the entities that act as CAs, RPs, and = repository operators in the RPKI, e.g., IANA, Internet Registries, and = network operators. It is also RECOMMENDED that the timeline document = describe procedures to track the progress of the transition and to amend = the timeline, e.g., if problems arise in implementing later phases of = the transition. I really think we should address these issues in a single document. It = seems like splitting this off into a separate/as yet unwritten document = is likely to cause some problems. In particular, since that document = does not yet exist, and it may not be written and adopted for some time, = this draft will not be complete on its own. I'm worried that it is hard = to judge this document's readiness w/o these timeline issues worked out = or even broached (as they may demand changes to this process). Besides, = isn't the corpus of drafts rather extensive already (w/o adding = another)? :) >=20 >=20 > You raised a question about the implications for CAs that do not = transition to the new algorithm suite, motivated by the last paragraph = of section 11. You posited that "=8A the implication is that if any CA = doesn't keep up (so to speak) they are considered invalid and therefore = would be un-routable?" That's not quite accurate. At the end of Phase 4 = the Internet resources of any CAs that have not made the transition will = be treated the same as resources that have not been protected via RPKI = certificates and ROAs. Participation in the RPKI is voluntary, so there = may always been unprotected resources in the public Internet. These are = not un-routable, but they are subject to hijacking. OK, I see. But, aren't there second-order effects of this that we have = to worry about? For example, if I am an ISP whose CA performs the = rollover properly, but my upstream's CA does not, then their CA's = failure to keep up will cause my ISP to no longer be able to participate = in BGPsec, right (because I'm no longer part of a contiguous BGPsec = island)? I realize this is a bit different than my original example, = but upon thinking about the motivation for my comment, my point was more = general. It was that transitioning a CA to this state can have very = undesirable effects. >=20 > You suggested that we codify how the community should deal with = problems that motivate delaying a phase transition. We're not writing = the timeline document now, but the text at the beginning of this message = is an effort to make sure such considerations are addressed in that = document. >=20 > You suggested that we add text, for each phase, saying "=8A what to do = if its success requirements are not met (exceptions, error legs, etc)." = Here's my proposed initial text to address your question: >=20 > Phase 0 is the start of the process, when a new algorithm suite has = been selected and the timeline published. The only problem I envision = that might arise at this stage, prior to Phase 1, is a discovery of a = problem that makes Suite B unacceptable. If this situation arises, the = algorithm document will have to be reissued with a new Suite B, and the = timeline document will be reissued. s/I envision/we envision/ >=20 > Phase 1 requires all CAs to be able to issue certificates under Suite = B. If a problem arises that makes this infeasible for a substantial = number of CAs, the timeline document can be reissued, pushing back this = date, and dates for subsequent milestones. CAs that are capable of = issuing Suite B certificates may continue to do so, if requested by = their child CAs. Since this phase does not require any RPs to process = signed objects under Suite B, and since Suite B product SHOULD be stored = at independent publication points, there is no adverse impact on RPs. kewl, thnx. One minor nit: can we rephrase one part for clarity. = Instead of "If a problem arises that makes this infeasible for a = substantial number of CAs," can we just specify a little bit about how = this is determined. Maybe something like, "If deems a problem to have = arisen that is significant enough to make this infeasible for a = significant enough number of CAs..." >=20 > Phase 2 requires that CAs MUST publish all signed products under Suite = B, as well as Suite A, and RP MAY be prepared to validate these products = using Suite B. If a problem arises that makes this infeasible for a = substantial number of CAs, the timeline document can be reissued, = pushing back this date and dates for subsequent milestones. (Since the = processing requirement for RPs here is MAY, if RPs have problems with = Suite B products this does not require pushing back the Phase 2 = milestone, but it does motivate delaying the start of Phase 3.) CAs that = are capable of publishing products under Suite B may continue to do so. = Phase 2, like Phase 1, does not require any RPs to process signed = objects under Suite B, and since Suite B product SHOULD be stored at = independent publication points, there is no adverse impact on RPs. First, same minor nit as above. Second, do we want to consider the case were we want to rollback = (perhaps an alg B has become unsuitable for some reason and we need to = choose a new alg B altogether)? I'm not saying the above text should be = yanked, maybe just augmented? >=20 > Phase 3 requires that RPs MUST be able to process Suite B signed = products, and RPs are encouraged to validate signed products using Suite = B. However, each RP is required to be able to fall back to using the = Suite A product if the Suite B product set cannot be validated. As = Section 4.6 notes, there are no CA behavior changes at this phase, so = there is no requirement for CA rollback. If a substantial number of RPs = are unable to process product sets signed with Suite B, this Phase could = be delayed, and subsequent milestones pushed back. There is no rollback = required here, as there is no change in CA behavior. I think this reads well. I just have the same rollback comment as above = (again, as a possible addition, not replacement text). >=20 > Phase 4 begins the phase out of Suite A. At this phase products sets = signed under the old algorithm suite may begin to disappear, i.e., CAs = MAY choose to not publish them anymore. This phase should be delayed if = it is determined that many RPs are not capable of processing the new = algorithm suite. There is no rollback required if this phase is delayed. = However, CAs should be reminded to not remove old algorithm suite A = product sets if this phase is delayed. Same rollback comment. Minor typo: s/products sets/product sets/ >=20 > Section 4.8 describes EOL for the old algorithm suite, i.e., it kills = off all support for the old algorithm suite. It is described as a return = to Phase 0. If we wait until Phase 0, then it may be a very, very long = time before the old Suite A is killed off. We may want to revisit this, = i.e., if we want to kill off the old algorithm suite sooner. > Your last comment deals with the question of top-down vs. laissez = faire algorithm transition. I think your comment is that we cannot = mandate adherence to the transition process and timeline. Use of the = RPKI, both the issuance of signed products and their consumption, is = optional. So, no, we cannot mandate adherence to this timeline. But, we = can establish a transition process and timeline for all CAs and RPs = that chose to follow it. The goal in establishing the process and = timeline is to minimize the cost to the community, as a whole, for the = transition. Externalization of cost is the appropriate term here (from = economics perspective) to describe what happens if one were to adopt the = laissez faire approach. (Chaos might be an alterative term :-)) I think this is a very strange comment (and I note that you said it = earlier in this email too). "Use of the RPKI... is optional." Is the = goal of this system to protect the global routing infrastructure or not? = Unless we are talking about making this an experimental expedition, and = are prepared to create a globally applicable system later? If the goal = is to secure the global routing system (note I am not saying universal = deployment in the foreseeable future, just global applicability), then = this is an operational non-starter. I do not believe it is appropriate = for us to try and re-legislate operational axioms in these drafts. What = we could be doing is grossly misaligning this standards work with = operational invariants. >=20 > First, not that a CA cannot unilaterally decide to transition to a new = algorithm. There is a requirement that the issuer of its certificate is = prepared to accept a certificate request under the new algorithm suite = (because of the PoP requirement). I'm sorry, I don't understand. >=20 > The exponential growth arises if we have Suite A and B product sets at = each tier. If we allow CAs to "do their own thing," there is the = potential for four combinations: > - a Suite A certificate issued under Suite A > - a Suite A certificate issued under Suite B > - a Suite B certificate issued under Suite A > - a Suite B certificate issued under Suite B >=20 > If we allow all of these combinations, which may be needed to allow = RPs to process signed products during the transition, then each tier has = this potential 4-way branching, to accommodate RPs at different stages = of algorithm capability. If you want more details, I suggest reviewing = the slides from the SIDR WG meeting that I believe I cited previously. = When Geoff Huston initially noted this problem, I disagreed, and it was = not until I started to write the spec that I realized what he meant. Indeed, I will take a look before coming back to this (to be sure I have = not missed anything), thanks. > To avoid more flame wars, I will duck your question about my views on = DNSSEC and accommodation of different algorithm suites :-). Shall I take that as a retraction of your comment? ;) Eric= From eosterweil@verisign.com Sun Nov 13 22:06:01 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35C611E820B for ; Sun, 13 Nov 2011 22:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58XKvOSNlpKk for ; Sun, 13 Nov 2011 22:06:01 -0800 (PST) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id EAF3A11E8207 for ; Sun, 13 Nov 2011 22:06:00 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKTsCvxh8EYOubuQmyKSxP/XWQ5SqY1jZx@postini.com; Sun, 13 Nov 2011 22:06:01 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id pAE65vnc028523; Mon, 14 Nov 2011 01:05:57 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.69]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Nov 2011 01:05:56 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Mon, 14 Nov 2011 14:05:56 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <72FA123B-43C9-44D5-A3BC-7DF71984662E@verisign.com> References: To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 14 Nov 2011 06:05:57.0251 (UTC) FILETIME=[79B21D30:01CCA293] Cc: sidr@ietf.org Subject: Re: [sidr] addendum X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 06:06:01 -0000 On Nov 14, 2011, at 1:21 PM, Stephen Kent wrote: > Eric, >=20 > I forgot to address an issue that you mentioned in a previous message, > and that relates to the alg agility doc. >=20 > The alg spec for the RPKI is separate from the CP, precisely so that = we could change the algs without changing the CP. So, when the alg spec = is replaced to introduce the next set of algs, we do not plan to = re-issue the CP. As a result, the cert policy OID will not change as a = side effect of the alg transition. >=20 > I discussed this assumption re OID stability with several PKI experts = today, and they agreed that there is no need to change the policy OID. >=20 > i mention this because I recall that a previous message touched on = this question, and I realize that the alg agility doc failed to mention = this. The next rev will make this explicit. Ah, very kewl. Thanks, Eric= From danny@tcb.net Sun Nov 13 22:08:05 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E873511E8207 for ; Sun, 13 Nov 2011 22:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lTJqZXn9dc2 for ; Sun, 13 Nov 2011 22:08:05 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 6873A11E80AB for ; Sun, 13 Nov 2011 22:08:05 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 13DEC268063; Sun, 13 Nov 2011 23:08:05 -0700 (MST) Received: from dhcp-1267.meeting.ietf.org (dhcp-1267.meeting.ietf.org [130.129.18.103]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sun, 13 Nov 2011 23:08:04 -0700 (MST) (envelope-from danny@tcb.net) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Mon, 14 Nov 2011 01:07:48 -0500 Content-Transfer-Encoding: 7bit Message-Id: <0892B192-DA37-4621-AC98-A5A48DBCFBEE@tcb.net> References: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> <6054A2B1-40D3-49E6-8972-946D426E830B@castlepoint.net> To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 06:08:06 -0000 On Nov 13, 2011, at 11:30 PM, Randy Bush wrote: > NotFound is a keyword. I assume it was derived from the normative pfx-validate draft and was simply hoping for consistent use: danny@pork% grep -i found draft-ietf-sidr-pfx-validate-03.txt peer will be found to have one of the following "validation states": o Not found: No ROA Covers the Route Prefix. //Initialize result to "not found" state result = BGP_PFXV_STATE_NOT_FOUND; //"not found" applies to this validation operation. will result in "not found" state and the prefixes will be advertised also result in "not found" state. The implementation is expected to "Not found" != "NotFound", that's all... Makes searching and dependency simpler. -danny From eosterweil@verisign.com Sun Nov 13 22:08:08 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9EE11E820F for ; Sun, 13 Nov 2011 22:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbBwstXUDFwg for ; Sun, 13 Nov 2011 22:08:08 -0800 (PST) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 91EA911E820B for ; Sun, 13 Nov 2011 22:08:07 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKTsCwR5kZKdPk7Go4w/Uoh1xV3MEJkRyy@postini.com; Sun, 13 Nov 2011 22:08:07 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id pAE686kW017927 for ; Mon, 14 Nov 2011 01:08:06 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.69]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Nov 2011 01:08:05 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Eric Osterweil In-Reply-To: Date: Mon, 14 Nov 2011 14:08:03 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: sidr wg list X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 14 Nov 2011 06:08:05.0737 (UTC) FILETIME=[C6478590:01CCA293] Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 06:08:08 -0000 Hey everyone, So, based on both a long flight, and the comments already made about = this draft, I re-read it and wanted to make the following additional = comments. I don't think these are redundant with the comments other = have made, but if any of them are, sorry for the noise. First, I think the notion and general tone of this document are great. = The software engineer in me is very excited to see a good requirements = doc at the early stages of a system design. I hope the remainder of my = comments can be read with this high-order bit set. :) - 3.5 is not a testable requirement. One cannot be expected to = enumerate the space of all things that are _not_ requirements, so why = put any in? - 3.6 ibid - 3.7 is too vague. Need to specify where an adversary needs to have = access to link-layer. I have access to the link layer at home, but that = doesn't help me insert traffic between any BGP peers. Can I suggest = modifying the existing text as follows: ``... an enemy who has access to the inter-router link layer...'' the = term ``inter-router link'' is borrowed from the cited RFC. - 3.8 The word ``MAY'' is a very rough fit for the general notion of = ``requirements.'' I would suggest it is reworded: ``A BGPsec design MUST be able to understand and make use of a = security infrastructure (e.g., a PKI) to distribute authenticated data = used as input to routing decisions when such a resource is available and = operators wish to configure it for use. Such data includes information = about holdings of address space and ASNs, and assertions about = binding of address space to ASNs.'' - 3.9 is also not worded as a requirement. Does the solution require = that a 4k packet even be discussed? It seems to me that this is not the = right document to discuss this. - 3.10 also does not seem to be a requirement. It is ``requiring'' an = optional exclusion? I suggest it get yanked. - 3.11 This also does not seem to be a requirement. Discussing a = design's status in a requirements document is backwards. I suggest this = get yanked. - 3.19 Seems like it would be hard to test as a requirement. The = problem may be the word ``MAY.'' How could this be made into a testable = requirement? - 3.20 This requirement, again, references a baked design. This should = be restated in a general way. Suggest, ``Any inter-AS use of cryptographic hashes or signatures, should = (must?) provide mechanisms for algorithm agility that take the form = of...'' - 4.5 The term ``real-time'' seems to carry too many implicit/overloaded = meanings. Could we try to disambiguate with different text. Maybe we = can just drop that term ``real-time'' and leave the rest? - 4.7 This requirement seems to preach a little bit of a design instead = of being agnostic. Could it be rephrased to be something like: ``The output of a router applying BGPsec to a received signed UPDATE = MUST be either unequivocal and conform to a fully specified state in the = design.'' Thanks, Eric From eosterweil@verisign.com Sun Nov 13 22:12:02 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9842F11E80AB for ; Sun, 13 Nov 2011 22:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SP50FEs-NO7g for ; Sun, 13 Nov 2011 22:12:02 -0800 (PST) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id 937DB11E80A6 for ; Sun, 13 Nov 2011 22:12:01 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKTsCxMFa3UHUCqcZ4VZCgcfFUO2Fg+N33@postini.com; Sun, 13 Nov 2011 22:12:01 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id pAE6C0mC028697 for ; Mon, 14 Nov 2011 01:12:00 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.69]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Nov 2011 01:11:59 -0500 From: Eric Osterweil Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Nov 2011 14:11:57 +0800 Message-Id: <2FCD590E-4AFD-44E3-BD67-2563C35CB565@verisign.com> To: sidr wg list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 14 Nov 2011 06:11:59.0990 (UTC) FILETIME=[51E7B160:01CCA294] Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 06:12:02 -0000 One other minor comment/question about this draft: The term ``Matched'' is defined, and only used once in combination with = covered. Considering that the document seems to (rightly) try to remain = decoupled/agnostic of the system design of the RPKI, is this distinction = important enought to keep? The benefit to dropping it would just be = less terminiology and might help readability. Thanks, Eric= From randy@psg.com Sun Nov 13 22:20:08 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCB311E80BE for ; Sun, 13 Nov 2011 22:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeJoNfYWPJX4 for ; Sun, 13 Nov 2011 22:20:08 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 29A9911E8095 for ; Sun, 13 Nov 2011 22:20:08 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RPptn-0000ZS-4E; Mon, 14 Nov 2011 06:20:07 +0000 Date: Mon, 14 Nov 2011 14:20:05 +0800 Message-ID: From: Randy Bush To: Danny McPherson In-Reply-To: <0892B192-DA37-4621-AC98-A5A48DBCFBEE@tcb.net> References: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> <6054A2B1-40D3-49E6-8972-946D426E830B@castlepoint.net> <0892B192-DA37-4621-AC98-A5A48DBCFBEE@tcb.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 06:20:08 -0000 > danny@pork% grep -i found draft-ietf-sidr-pfx-validate-03.txt > peer will be found to have one of the following "validation states": > o Not found: No ROA Covers the Route Prefix. > //Initialize result to "not found" state > result = BGP_PFXV_STATE_NOT_FOUND; > //"not found" applies to this validation operation. > will result in "not found" state and the prefixes will be advertised > also result in "not found" state. The implementation is expected > to talk to those authors :) chris checked roa-validation and now we have "unknown" as well. oh goodie randy From danny@tcb.net Sun Nov 13 22:24:45 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDBE11E815A for ; Sun, 13 Nov 2011 22:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDZdAmc67+FY for ; Sun, 13 Nov 2011 22:24:45 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 64A9511E80BE for ; Sun, 13 Nov 2011 22:24:45 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 3676F268063; Sun, 13 Nov 2011 23:24:45 -0700 (MST) Received: from dhcp-1267.meeting.ietf.org (dhcp-1267.meeting.ietf.org [130.129.18.103]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sun, 13 Nov 2011 23:24:45 -0700 (MST) (envelope-from danny@tcb.net) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Mon, 14 Nov 2011 01:24:27 -0500 Content-Transfer-Encoding: 7bit Message-Id: <2D5C11B3-B33E-4215-B15C-C10B0D581C57@tcb.net> References: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> <6054A2B1-40D3-49E6-8972-946D426E830B@castlepoint.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 06:24:46 -0000 On Nov 13, 2011, at 11:03 PM, Christopher Morrow wrote: > I suspect some feedback to Danny will come soonish, but can we close > out the other set of requests? Chris, I'm not sure I understand the request, can you clarify? I.e., until I've had adequate time to review updated I-Ds with changes incorporated in context it's hard to determine if we can close on those issues. -danny From christopher.morrow@gmail.com Sun Nov 13 22:29:02 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB13611E81BA for ; Sun, 13 Nov 2011 22:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.538 X-Spam-Level: X-Spam-Status: No, score=-103.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B43enHMxWiRw for ; Sun, 13 Nov 2011 22:29:02 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7045A11E80BE for ; Sun, 13 Nov 2011 22:29:02 -0800 (PST) Received: by iaeo4 with SMTP id o4so8883508iae.31 for ; Sun, 13 Nov 2011 22:29:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=sxekXY2LRzjWJguWbR9uzp67xDPAMWko7iEilhU/RDk=; b=QCz6FzDQPPZkgkL3nOu4M/Gc/iZ1EnwDOiyUyU2M4sZ8dfSp6XBflQfH7QOo71ovfb Nzx/wX7dwF2KFizXVGXYs6XfVIsyAxqh25B616MJnqvPmfSHeYHYhxeoaimwnaY2b9xx cyFpHdc1dWUUQZLMTkfWIdlBWysxe5++HOn1c= MIME-Version: 1.0 Received: by 10.231.68.20 with SMTP id t20mr5013739ibi.18.1321252142149; Sun, 13 Nov 2011 22:29:02 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Sun, 13 Nov 2011 22:29:02 -0800 (PST) In-Reply-To: <2D5C11B3-B33E-4215-B15C-C10B0D581C57@tcb.net> References: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> <6054A2B1-40D3-49E6-8972-946D426E830B@castlepoint.net> <2D5C11B3-B33E-4215-B15C-C10B0D581C57@tcb.net> Date: Mon, 14 Nov 2011 01:29:02 -0500 X-Google-Sender-Auth: uNZhhhnXMVIdoGB1T5WIPIm9-zc Message-ID: From: Christopher Morrow To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 06:29:03 -0000 On Mon, Nov 14, 2011 at 1:24 AM, Danny McPherson wrote: > > On Nov 13, 2011, at 11:03 PM, Christopher Morrow wrote: > >> I suspect some feedback to Danny will come soonish, but can we close >> out the other set of requests? > > Chris, > I'm not sure I understand the request, can you clarify? can try :) > I.e., until I've had adequate time to review updated I-Ds with changes > incorporated in context it's hard to determine if we can close on those > issues. > there were a slew of changes (or a slew of comments made) requested, a document update happened ~13 days ago, did the changes account for the comments/requests or not? The outstanding (today) new request I get won't be dealt with yet, but it seems from the conversation between you/randy that it's moving in the right direction, no? -chris > -danny > From wesley.george@twcable.com Sun Nov 13 22:40:53 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB7911E8227 for ; Sun, 13 Nov 2011 22:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.867 X-Spam-Level: X-Spam-Status: No, score=-0.867 tagged_above=-999 required=5 tests=[AWL=0.596, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuRgz5MkvJiH for ; Sun, 13 Nov 2011 22:40:53 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 70DBB11E8225 for ; Sun, 13 Nov 2011 22:40:53 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,506,1315195200"; d="scan'208";a="296945973" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 14 Nov 2011 01:36:26 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Mon, 14 Nov 2011 01:40:52 -0500 From: "George, Wes" To: Christopher Morrow , Danny McPherson Date: Mon, 14 Nov 2011 01:41:15 -0500 Thread-Topic: [sidr] WGLC: draft-ietf-sidr-origin-ops Thread-Index: AcyilrQgCCqXhWqXSdiw4amAJdRIrQAANsuQ Message-ID: References: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> <6054A2B1-40D3-49E6-8972-946D426E830B@castlepoint.net> <2D5C11B3-B33E-4215-B15C-C10B0D581C57@tcb.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 06:40:54 -0000 > From: christopher.morrow@gmail.com > there were a slew of changes (or a slew of comments made) requested, a > document update happened ~13 days ago, did the changes account for the > comments/requests or not? > [WEG] I diffed 11 and 12 when 12 came out, and no, not really. As I recall,= Shane already replied that the proposed text (that made it into -12) was n= ot adequate in explaining rationale around the recommendation of "close" fo= r RPKI cache placement, among other things. (cf. emails on 10/31). Don't kn= ow if additional changes are pending for -13 based on those comments, but t= he mail thread died on the 31st with no further responses. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From randy@psg.com Sun Nov 13 22:45:55 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D7611E8227 for ; Sun, 13 Nov 2011 22:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKyaMUuqtxnN for ; Sun, 13 Nov 2011 22:45:55 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id E4A6011E8226 for ; Sun, 13 Nov 2011 22:45:54 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RPqIj-0000bU-Q2; Mon, 14 Nov 2011 06:45:54 +0000 Date: Mon, 14 Nov 2011 14:45:52 +0800 Message-ID: From: Randy Bush To: Shane Amante In-Reply-To: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> References: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 06:45:56 -0000 > 1) From Section 3: > ---snip--- > A local valid cache containing all RPKI data may be gathered from the > global distributed database using the rsync protocol, [RFC5781], and > a validation tool such as rcynic [rcynic]. > ---snip--- > > Would it be possible to mention and/or point to how the above process > is supposed to be bootstrapped? IOW, is it expected that, > eventually?, the RIR's are going to publish to their end-users and > maintain URI's of RPKI publication points? Since this is an Ops > guidelines document, some guidance and/or pointers are likely to save > [lots of] questions down the road. I'm not expecting this to be a > tutorial document, but some idea on the theory of how a new SP > bootstraps their cache(s) would be helpful. that is software dependent. relying party software and how it decides to deal with the global rpki is very software dependent. e.g. tim's varies from rob's, and we have some really wild ideas to deal with the issues of reliable distributed publication. it has been suggested that you may be asking how the inter-publication stuff is to be bootstrapped at the global rpki level. this is the sia pointer in the cert. when i tell arin i want my space and will publish at uri://randy.foo, they put the cert in their pub point with an sia pointer to uri://randy.foo > 2) Given that, to my knowledge, the RPKI is [very] loosely > synchronized in a "pull-only" fashion, shouldn't there be some > text added below to that effect that: > a) It may not be best to go more than, say, 2 levels of RPKI > caches deep inside a single organization/ASN to avoid RPKI caches > from being out of sync with each other? considering the timings we are seeing in operation, like a few seconds to fetch from one cache to another, as compared to minutes to load from the global rpki (see rob's preso at iepg) and my comment above, this may be 180 degrees out. inter-cache fetching may be far better. but code will vary. > b) Operators should look at running more aggressive > synchronization intervals _internally_ within their organization/ASN, > from "children" (2nd-level) RPKI caches to the 'parent' (top-level) > RPKI cache in their organization/ASN, compared to more "relaxed" > synchronization intervals to RPKI caches external to their > organization (top-level RPKI caches in their ASN to RIR's)? kind of assumed in current text, but i can add something. > ---snip--- > Validated caches may also be created and maintained from other > validated caches. Network operators SHOULD take maximum advantage of > this feature to minimize load on the global distributed RPKI > database. Of course, the recipient SHOULD re-validate the data. > ---snip--- > While I'm here, I don't think the text in Section 6, "Notes", > addresses the above concerns, at all. In fact, I find it extremely > unhelpful to just dismiss this concern, out of hand, with the text: > "There is no 'fix' for this, it is the nature of distributed data > with distributed caches". We know what the answer is here for some values of "we." > you tune the synchronization intervals to strike the appropriate > balance between [very] tight synchronization vs. increased load on > the systems being synchronized. could you reference an example, a paper, an algorithm, ...? we seem to think differently about how easy this is. > I find it hard to believe a simple suggestion such as this is not > proposed in the text, even including the phrase "the suggested > values for such synchronization are outside the scope of this > document, but will likely be subject to further studies to > determine optimal values based on field experience". ahhhh. so we don't know. i say that frequently! It is hoped that testing and deployment will produce advice on relying party cache loading and timing. > 3) Granted, the following text is only a "SHOULD", but the text > offers no reasoning as to why caches should be placed close to > routers, i.e.: are there latency concerns (for the RPKI <-> cache > protocol), or is it that a geographically distributed system is one > way to avoid a single-point-of-failure, or something else entirely? > As a start, just defining "close" would help, e.g.: same POP, same > (U.S.) state, same country, same timezone i seem to get in trouble every time i do so. it's an ietf thing. > but, then a statement as to any latency or resiliency requirement for > geographic deployment of RPKI caches wold be useful. so far, actual timings seem not to be very latency sensitive, probably because they have been done with freebsd on fat wires. as i said on this thread on nanog, this is why we get the big bucks. it is a multi-dimensional design issue. > Furthermore, given the [very] loosely synchronized nature of the > RPKI, should the text point out that the number of RPKI caches > (internal to the organization) be balanced against the potential need > of an organization to maintain a more tightly synchronized view, > across their entire network, of validated routing information? i have no idea. you seem to think inter-cache sync dominates timing far more than i do. i suspect that publishing party timing dominates. so send text. > A concern might be that if routers in Continent A pull information > from their RPKI caches that tell them that ROA is not "Invalid", but > other routers in Continent B are still using 'older' information in > RPKI caches in Continent B that says the same ROA is either "Not > Found" or "Valid", then the result might be that BGP Path Selection > swings all traffic from Continent A to Continent B. At a minimum, > this could lead to substantially increased latency or, at worst, > congestion, packet-loss or a unintended DoS. yep, that is a concern. how deeply do we want to get into explaining all the issues surrounding distributed data? at this point i am tempted to point to a basic cs text on the subject. > In the short-term, the LOCAL_PREF Attribute may be used to carry > both the validity state of a prefix along with it's Traffic > Engineering characteristic(s). It is likely that the SP will have to > change their BGP policies such that they can encode these two, > separate characteristics in the same BGP attribute without negatively > impacting their existing use or leading to accidental privilege > escalation attacks. thanks for text > 5) I have three comments on the below: > a) It's not clear, to me, what is meant by "internal metric" > below. Do you mean MED or IGP metric or something else? I don't > see IGP metric as being practical, so I'm assuming you mean > additively altering MED (up|down) based on validity state. > Regardless, I would recommend you state more precisely which BGP > Path Attribute you're referring to below. > b) Since MED is passed from one ASN to (only) a second, downstream ASN to influence ingress TE policy, is it "OK" from a security PoV that MED is a *trusted* means to convey ROA validity information from one ASN to a second? Presumably, the answer should be "heck, no", right? If that's the case, then wouldn't it be wise to state that: > i) MED's, encoded with any ROA validity information, should get reset on egress from an ASN to remove said validity information and only carry TE information, as appropriate; and, > ii) MED's should not be trusted on ingress to convey any meaning with respect to validity information? > c) What is meant by the statement, "might choose to let AS-Path rule"? Is your intent to state that an SP may choose to just use MED, which follows after LOCAL_PREF & AS_PATH in the BGP Path Selection Algorithm, as a means to determining validity of a particular prefix? If so, then it would be much more clear if you just stated that, e.g.: > ==== > If LOCAL_PREF is not used to convey validity information, then MED > is likely the next best candidate BGP Attribute that can be used > to influence path selection based on the validity of a particular > prefix. As with LOCAL_PREF, care must be taken to avoid changing > the MED attribute and creating privilege escalation attacks. Other providers may not want the RPKI validation result to be more important than AS-path length -- these providers would need to map RPKI validation result to some BGP attribute that is evaluated in BGP's path selection process after AS-path is evaluated. Routers implementing RPKI-based origin validation MUST provide such options to operators. > 7) Is this document only intended (scoped?) to cover PE's that can > (or, eventually, will) speak the RPKI-RTR protocol for validation? yes randy From internet-drafts@ietf.org Sun Nov 13 23:03:55 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A2311E80AD; Sun, 13 Nov 2011 23:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8OjxB1u3+5I; Sun, 13 Nov 2011 23:03:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D8B11E8171; Sun, 13 Nov 2011 23:03:50 -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: 3.63 Message-ID: <20111114070350.25786.17832.idtracker@ietfa.amsl.com> Date: Sun, 13 Nov 2011 23:03:50 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-origin-ops-13.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 07:03:57 -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 G= roup of the IETF. Title : RPKI-Based Origin Validation Operation Author(s) : Randy Bush Filename : draft-ietf-sidr-origin-ops-13.txt Pages : 10 Date : 2011-11-13 Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present them. It is expected to evolve as RPKI-based origin validation is deployed and the dynamics are better understood. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-13.txt From christopher.morrow@gmail.com Sun Nov 13 23:07:05 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75AA21F84CC for ; Sun, 13 Nov 2011 23:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.54 X-Spam-Level: X-Spam-Status: No, score=-103.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzKjxieQaflm for ; Sun, 13 Nov 2011 23:07:02 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 567D011E80BD for ; Sun, 13 Nov 2011 23:06:59 -0800 (PST) Received: by iaeo4 with SMTP id o4so8922871iae.31 for ; Sun, 13 Nov 2011 23:06:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4dsI/CNOJh5RtwYEFz9EhVFSE2uyFzht5wvBNHfoOtc=; b=n8w8aoIN0YOEXrw2JKp5qUDLMpHcbSkGbJIIEHcefMqjUUPyRG3ATS/0i/TClsz96U J2bNvyRtBLus7XI7qVKXVYLs9umlqXPiFOTBLGUWMKHZb2LUfMbyJNnFo2PxYKP5fnMM FnByCVS50nc4LRq5mJMfGvoVh+o22dvTImbm8= MIME-Version: 1.0 Received: by 10.231.48.142 with SMTP id r14mr5025544ibf.5.1321254406714; Sun, 13 Nov 2011 23:06:46 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Sun, 13 Nov 2011 23:06:46 -0800 (PST) In-Reply-To: References: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> <6054A2B1-40D3-49E6-8972-946D426E830B@castlepoint.net> <2D5C11B3-B33E-4215-B15C-C10B0D581C57@tcb.net> Date: Mon, 14 Nov 2011 02:06:46 -0500 X-Google-Sender-Auth: fweTTwTVJtivNDmCz45zmFaW2ZE Message-ID: From: Christopher Morrow To: "George, Wes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 07:07:05 -0000 On Mon, Nov 14, 2011 at 1:41 AM, George, Wes wr= ote: > >> From: christopher.morrow@gmail.com > >> there were a slew of changes (or a slew of comments made) requested, a >> document update happened ~13 days ago, did the changes account for the >> comments/requests or not? >> > > [WEG] I diffed 11 and 12 when 12 came out, and no, not really. As I recal= l, Shane already replied that the proposed text (that made it into -12) was= not adequate in explaining rationale around the recommendation of "close" = for RPKI cache placement, among other things. (cf. emails on 10/31). Don't = know if additional changes are pending for -13 based on those comments, but= the mail thread died on the 31st with no further responses. > ok, I was/am looking for status. I think randy replied to shane's note (or another note form shane) a bit ago, and talks some about 'close'. I believe that a new version just arrived in the repository as well. -chris > Wes George > > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > From shane@castlepoint.net Mon Nov 14 02:45:17 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8899F11E8163 for ; Mon, 14 Nov 2011 02:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ3xZAYwL9mc for ; Mon, 14 Nov 2011 02:45:16 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 6112611E8156 for ; Mon, 14 Nov 2011 02:45:16 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 18F78268063; Mon, 14 Nov 2011 03:45:16 -0700 (MST) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 14 Nov 2011 03:45:15 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=50305; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Mon, 14 Nov 2011 18:45:09 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <48A7C4A7-7FFB-44CB-ABCA-76E148AE0574@castlepoint.net> References: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> To: Randy Bush X-Mailer: Apple Mail (2.1251.1) Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 10:45:17 -0000 Hi Randy, Thanks for the response. I think we're getting closer. See below. On Nov 14, 2011, at 2:45 PM, Randy Bush wrote: >> 1) =46rom Section 3: >> ---snip--- >> A local valid cache containing all RPKI data may be gathered from = the >> global distributed database using the rsync protocol, [RFC5781], = and >> a validation tool such as rcynic [rcynic]. >> ---snip--- >>=20 >> Would it be possible to mention and/or point to how the above process >> is supposed to be bootstrapped? IOW, is it expected that, >> eventually?, the RIR's are going to publish to their end-users and >> maintain URI's of RPKI publication points? Since this is an Ops >> guidelines document, some guidance and/or pointers are likely to save >> [lots of] questions down the road. I'm not expecting this to be a >> tutorial document, but some idea on the theory of how a new SP >> bootstraps their cache(s) would be helpful. >=20 > that is software dependent. relying party software and how it decides > to deal with the global rpki is very software dependent. e.g. tim's > varies from rob's, and we have some really wild ideas to deal with the > issues of reliable distributed publication. >=20 > it has been suggested that you may be asking how the inter-publication > stuff is to be bootstrapped at the global rpki level. this is the sia > pointer in the cert. when i tell arin i want my space and will = publish > at uri://randy.foo, they put the cert in their pub point with an sia > pointer to uri://randy.foo Yes, I'm asking about the latter. More specifically, what I've been = attempting to ask here is how one configures, in one's _local_ RPKI = cache (that syncs to the outside world), /where/ the RIR's publication = points are on Day 1. Do I contact one RIR (which maintains a list of = other RIR's publication points) -or- each RIR individually to ask what = is their publication point? (If you can help provide an answer as to = what is the expectation on the operator, I can then potentially help to = provide text). >> 2) Given that, to my knowledge, the RPKI is [very] loosely >> synchronized in a "pull-only" fashion, shouldn't there be some >> text added below to that effect that:=20 >> a) It may not be best to go more than, say, 2 levels of RPKI >> caches deep inside a single organization/ASN to avoid RPKI caches >> from being out of sync with each other? >=20 > considering the timings we are seeing in operation, like a few seconds > to fetch from one cache to another, as compared to minutes to load = from > the global rpki (see rob's preso at iepg) and my comment above, this = may > be 180 degrees out. inter-cache fetching may be far better. > > but code will vary. I'm going to put this comment aside for the moment, since I think the = issue below wrt the desire (or, need?) to deploy RPKI servers across the = whole network may be a better way to answer the above. >> b) Operators should look at running more aggressive >> synchronization intervals _internally_ within their organization/ASN, >> from "children" (2nd-level) RPKI caches to the 'parent' (top-level) >> RPKI cache in their organization/ASN, compared to more "relaxed" >> synchronization intervals to RPKI caches external to their >> organization (top-level RPKI caches in their ASN to RIR's)?=20 >=20 > kind of assumed in current text, but i can add something. OK, thanks. >> ---snip--- >> Validated caches may also be created and maintained from other >> validated caches. Network operators SHOULD take maximum advantage = of >> this feature to minimize load on the global distributed RPKI >> database. Of course, the recipient SHOULD re-validate the data. >> ---snip--- >> While I'm here, I don't think the text in Section 6, "Notes", >> addresses the above concerns, at all. In fact, I find it extremely >> unhelpful to just dismiss this concern, out of hand, with the text: >> "There is no 'fix' for this, it is the nature of distributed data >> with distributed caches". We know what the answer is here >=20 > for some values of "we." >=20 >> you tune the synchronization intervals to strike the appropriate >> balance between [very] tight synchronization vs. increased load on >> the systems being synchronized. >=20 > could you reference an example, a paper, an algorithm, ...? we seem = to > think differently about how easy this is. >=20 >> I find it hard to believe a simple suggestion such as this is not >> proposed in the text, even including the phrase "the suggested >> values for such synchronization are outside the scope of this >> document, but will likely be subject to further studies to >> determine optimal values based on field experience". >=20 > ahhhh. so we don't know. i say that frequently! >=20 > It is hoped that testing and deployment will produce advice on > relying party cache loading and timing. OK. How about the following tweak: ---snip--- It is hoped that testing and deployment will produce advice on RPKI cache loading, intra-domain and inter-domain RPKI cache = synchronization timing, router to RPKI cache synchronization timing, etc. ---snip--- >> 3) Granted, the following text is only a "SHOULD", but the text >> offers no reasoning as to why caches should be placed close to >> routers, i.e.: are there latency concerns (for the RPKI <-> cache >> protocol), or is it that a geographically distributed system is one >> way to avoid a single-point-of-failure, or something else entirely? >> As a start, just defining "close" would help, e.g.: same POP, same >> (U.S.) state, same country, same timezone=20 >=20 > i seem to get in trouble every time i do so. it's an ietf thing. >=20 >> but, then a statement as to any latency or resiliency requirement for >> geographic deployment of RPKI caches wold be useful. >=20 > so far, actual timings seem not to be very latency sensitive, probably > because they have been done with freebsd on fat wires. >=20 > as i said on this thread on nanog, this is why we get the big bucks. = it > is a multi-dimensional design issue. This still hasn't answered the question. Let me try again. Money doesn't grow on trees. Why is it 'advised' (SHOULD) that I deploy = a RPKI cache in every single POP throughout my whole network? Funny = thing about business folks that control the budget, they want an answer = to this question that is other than "because". Let me try to now be = more constructive. Is this draft recommending RPKI cache per POP: 1) For [massive] redundancy/resiliency inside the AS; 2) To keep CPU (or, network) 'load' down on RPKI caches inside the AS = -- even though, above, you've said that this hasn't been quantified, = yet? 3) To keep latency down in order to ensure the fastest possible = inter-cache sync time -or- router to RPKI cache fetching time? 4) To avoid reliance on either IGP -or- BGP within the AS for a router = to get access to it's RPKI cache for data? 5) Other? 6) All of the above? Ideally, you can narrow it down to just one answer from above, but if = not which of the above are the "most important" and driving this = recommendation? Furthermore, this is not just about the cost of the server HW on top of = which one would run RPKI inside the AS. There is also much more = substantial costs associated with [potentially violent] swings of = traffic around the network as the "loosely synchronized" (out-of-band) = RPKI caches push new RPKI data to routers -or- routers pull new RPKI = data from their local RPKI cache that may be different from neighboring = RPKI caches inside the same network. In theory, one way to "solve" this = problem is to deploy [much] less RPKI caches inside the AS, thus = ensuring that a "large" collection of routers have a consistent view of = the same RPKI data. >> Furthermore, given the [very] loosely synchronized nature of the >> RPKI, should the text point out that the number of RPKI caches >> (internal to the organization) be balanced against the potential need >> of an organization to maintain a more tightly synchronized view, >> across their entire network, of validated routing information? >=20 > i have no idea. you seem to think inter-cache sync dominates timing = far > more than i do. i suspect that publishing party timing dominates. >=20 > so send text. See just below for what is my primary concern. >> A concern might be that if routers in Continent A pull information >> from their RPKI caches that tell them that ROA is not "Invalid", but >> other routers in Continent B are still using 'older' information in >> RPKI caches in Continent B that says the same ROA is either "Not >> Found" or "Valid", then the result might be that BGP Path Selection >> swings all traffic from Continent A to Continent B. At a minimum, >> this could lead to substantially increased latency or, at worst, >> congestion, packet-loss or a unintended DoS. >=20 > yep, that is a concern. >=20 > how deeply do we want to get into explaining all the issues = surrounding > distributed data? at this point i am tempted to point to a basic cs > text on the subject. So, I think there are two issues here: 1) Inter-RPKI cache synchronization _within_ an AS <-- something an = individual operator does have a lot of control over; and, 2) Inter-RPKI cache synchronization _between_ AS'es (technically, = amongst all the authoritative, global RPKI caches in the world) <-- = something an individual operator does not have much, if any, control = over. FWIW, my comment above is in regards to #1. More specifically, with = respect to the recommendation to deploy RPKI caches in every POP, = globally, there is a [very] large risk (?) that those RPKI caches inside = the network will be "loosely synchronized". Thus, different RPKI caches = will be updating BGP policy with their associated routers at much (?) = different time intervals. This results in BGP path selection = calculating a new best path and shifting traffic around the network, = until _all_ RPKI caches (intra-AS) have updated their associated router, = thus getting BGP policy back to an "optimal" state of load-sharing = traffic across, say, all connections to a multi-homed customer or peer. I also think there's substantial operational issues wrt #2, but I don't = have a palatable suggestion to offer. >> In the short-term, the LOCAL_PREF Attribute may be used to carry >> both the validity state of a prefix along with it's Traffic >> Engineering characteristic(s). It is likely that the SP will have to >> change their BGP policies such that they can encode these two, >> separate characteristics in the same BGP attribute without negatively >> impacting their existing use or leading to accidental privilege >> escalation attacks. =20 >=20 > thanks for text >=20 >> 5) I have three comments on the below: >> a) It's not clear, to me, what is meant by "internal metric" >> below. Do you mean MED or IGP metric or something else? I don't >> see IGP metric as being practical, so I'm assuming you mean >> additively altering MED (up|down) based on validity state. >> Regardless, I would recommend you state more precisely which BGP >> Path Attribute you're referring to below.=20 >> b) Since MED is passed from one ASN to (only) a second, = downstream ASN to influence ingress TE policy, is it "OK" from a = security PoV that MED is a *trusted* means to convey ROA validity = information from one ASN to a second? Presumably, the answer should be = "heck, no", right? If that's the case, then wouldn't it be wise to = state that: >> i) MED's, encoded with any ROA validity information, should = get reset on egress from an ASN to remove said validity information and = only carry TE information, as appropriate; and, >> ii) MED's should not be trusted on ingress to convey any = meaning with respect to validity information? >> c) What is meant by the statement, "might choose to let AS-Path = rule"? Is your intent to state that an SP may choose to just use MED, = which follows after LOCAL_PREF & AS_PATH in the BGP Path Selection = Algorithm, as a means to determining validity of a particular prefix? = If so, then it would be much more clear if you just stated that, e.g.: >> =3D=3D=3D=3D >> If LOCAL_PREF is not used to convey validity information, then MED >> is likely the next best candidate BGP Attribute that can be used >> to influence path selection based on the validity of a particular >> prefix. As with LOCAL_PREF, care must be taken to avoid changing >> the MED attribute and creating privilege escalation attacks. >=20 > Other providers may not want the RPKI validation result to be = more > important than AS-path length -- these providers would need to = map > RPKI validation result to some BGP attribute that is evaluated in > BGP's path selection process after AS-path is evaluated. Routers > implementing RPKI-based origin validation MUST provide such > options to operators. OK. >> 7) Is this document only intended (scoped?) to cover PE's that can >> (or, eventually, will) speak the RPKI-RTR protocol for validation? >=20 > yes OK. -shane= From kotikalapudi.sriram@nist.gov Mon Nov 14 03:14:13 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F70E11E8234 for ; Mon, 14 Nov 2011 03:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKAFIOYu6g3j for ; Mon, 14 Nov 2011 03:14:12 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF0911E81E8 for ; Mon, 14 Nov 2011 03:14:11 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 14 Nov 2011 06:14:08 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 14 Nov 2011 06:13:32 -0500 From: "Sriram, Kotikalapudi" To: Brian Dickson Date: Mon, 14 Nov 2011 06:13:32 -0500 Thread-Topic: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs) Thread-Index: AQHMor5xosDF2n1HPkGttBtzThsGyQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 11:14:13 -0000 Brian, For BGP-4 updates, Geoff does provide the peak numbers observed for prefix updates in 1 second intervals. http://bgpupdates.potaroo.net/instability/bgpupd.html For example: Peak Prefix Update Rate per second: 1539 while Average Prefix Updates per second: 2.76 I suspect the peak perhaps corresponds to BGP session reset events when updates are generated back-to-back. If you exclude those reset events, then BGP-4 chattiness will have low variance. Since we do not have operational BGPSEC yet, we cannot obtain similar measurements at present. But I am confident that if you focus on BGPSEC chattiness only due to beaconing (i.e., exclude BGP session resets events), then the burstiness (of BGPSEC beacons alone) will be low. Bear in mind that the protocol recommends beacons should be jittered in time, and when thousands of prefixes are beaconed in a time-jittered fashion from distributed sites, they smooth out and the resulting beacon arrival process at a router would be a rather smooth Poisson process (variance/mean = 1). So the peak # beacons in n-second intervals (for n>=1) will likely be a small multiple of the mean # beacons in n-second intervals. Again mind you, on the otherhand, if BGPSEC session resets occur, then that would be quite different -- thousands of BGPSEC updates (not beacons) would be sent back-to-back in that case between the two affected peers. It may be noted that operators are anyway used to allowing 10s of seconds for table convergence after session resets. (You will see an analysis of convergence following BGPSEC session reset in the presentation that Randy and I have in the SIDR WG meeting tomorrow.) Sriram ________________________________________ >From: Brian Dickson [brian.peter.dickson@gmail.com] > >Hi, Sriram, > >Could you supply similar kinds of numbers, but with "peak" instead of >"average", esp. 50%ile, 75%ile, and 95%-ile levels for "peak"? > >Average is much less important than peak, in my experience. >Steady-state is easy. > >Also, in noisy/spiky data, mean != median typically. BGP is noisy/spiky. > >(Also when doing percentiles, it is essential to say, "95%ile on >5-minute samples, over a period of 1 week" for instance - and those >would be the customary sample windows to use.) > >Thanks, >Brian From jakob.heitz@ericsson.com Mon Nov 14 04:25:56 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A5311E8086 for ; Mon, 14 Nov 2011 04:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrsYpUgPNJa7 for ; Mon, 14 Nov 2011 04:25:55 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id D674521F8D6D for ; Mon, 14 Nov 2011 04:25:55 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAECPpck009210; Mon, 14 Nov 2011 06:25:53 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 14 Nov 2011 07:25:47 -0500 From: Jakob Heitz To: "Sriram, Kotikalapudi" , Brian Dickson Date: Mon, 14 Nov 2011 07:25:45 -0500 Thread-Topic: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs) Thread-Index: AQHMor5xosDF2n1HPkGttBtzThsGyZWsRYYQ Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 12:25:56 -0000 It will be as bursty as the sender of the bursts pleases. A great way for the receiver of those non-urgent bursts to insulate itself is to send them in a different tcp session than regular BGP updates. It can then throttle the BGPSEC bursts without affecting regular BGP. If you consider a BGPSEC update only to be a signature for a regular update, then there is no race condition. In other words, to advertise a route, BGP needs to send an unsigned update in the regular session, as well as a signed one in the non-urgent BGPSEC session. An unsigned route is still useable in the absence of a signed one. It is simply "NotFound" instead of "Valid". If you put the BGPSEC traffic into a separate non-urgent session, this spruce goose might just get off the ground. -- Jakob Heitz. > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf > Of Sriram, Kotikalapudi > Sent: Monday, November 14, 2011 3:14 AM > To: Brian Dickson > Cc: sidr wg list > Subject: Re: [sidr] Burstiness of BGP updates (was: WGLC: draft- > ietf-sidr-bgpsec-reqs) >=20 > Brian, >=20 > For BGP-4 updates, Geoff does provide the peak numbers observed for > prefix updates in 1 second intervals. > http://bgpupdates.potaroo.net/instability/bgpupd.html > For example: > Peak Prefix Update Rate per second: 1539 > while > Average Prefix Updates per second: 2.76 I suspect the peak perhaps > corresponds to BGP session reset events when updates are generated > back-to-back. > If you exclude those reset events, then BGP-4 chattiness will have > low variance. >=20 > Since we do not have operational BGPSEC yet, we cannot obtain > similar measurements at present. But I am confident that if you > focus on BGPSEC chattiness only due to beaconing (i.e., exclude BGP > session resets events), then the burstiness (of BGPSEC beacons > alone) will be low. > Bear in mind that the protocol recommends beacons should be jittered > in time, and when thousands of prefixes are beaconed in a time- > jittered fashion from distributed sites, they smooth out and the > resulting beacon arrival process at a router would be a rather > smooth Poisson process (variance/mean =3D 1). > So the peak # beacons in n-second intervals (for n>=3D1) will likely > be a small multiple of the mean # beacons in n-second intervals. > Again mind you, on the otherhand, if BGPSEC session resets occur, > then that would be quite different -- thousands of BGPSEC updates > (not beacons) would be sent back-to-back in that case between the > two affected peers. > It may be noted that operators are anyway used to allowing 10s of > seconds for table convergence after session resets. > (You will see an analysis of convergence following BGPSEC session > reset > in the presentation that Randy and I have in the SIDR WG meeting > tomorrow.) >=20 > Sriram > ________________________________________ > >From: Brian Dickson [brian.peter.dickson@gmail.com] > > > >Hi, Sriram, > > > >Could you supply similar kinds of numbers, but with "peak" instead > of > >"average", esp. 50%ile, 75%ile, and 95%-ile levels for "peak"? > > > >Average is much less important than peak, in my experience. > >Steady-state is easy. > > > >Also, in noisy/spiky data, mean !=3D median typically. BGP is > noisy/spiky. > > > >(Also when doing percentiles, it is essential to say, "95%ile on > >5-minute samples, over a period of 1 week" for instance - and those > >would be the customary sample windows to use.) > > > >Thanks, > >Brian > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From sra@hactrn.net Mon Nov 14 05:37:29 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCCA11E80E9 for ; Mon, 14 Nov 2011 05:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.244 X-Spam-Level: X-Spam-Status: No, score=-102.244 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50ehbN0vDAmY for ; Mon, 14 Nov 2011 05:37:12 -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 2F27111E80DA for ; Mon, 14 Nov 2011 05:37:12 -0800 (PST) Received: from minas-ithil.hactrn.net (dhcp-45b6.meeting.ietf.org [130.129.69.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id A999B2846B for ; Mon, 14 Nov 2011 13:37:08 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 72C05654865 for ; Mon, 14 Nov 2011 21:37:04 +0800 (CST) Date: Mon, 14 Nov 2011 21:37:04 +0800 From: Rob Austein To: sidr@ietf.org In-Reply-To: <48A7C4A7-7FFB-44CB-ABCA-76E148AE0574@castlepoint.net> References: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> <48A7C4A7-7FFB-44CB-ABCA-76E148AE0574@castlepoint.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20111114133704.72C05654865@minas-ithil.hactrn.net> Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 13:37:29 -0000 At Mon, 14 Nov 2011 18:45:09 +0800, Shane Amante wrote: > > More specifically, what I've been attempting to ask here is how one > configures, in one's _local_ RPKI cache (that syncs to the outside > world), /where/ the RIR's publication points are on Day 1. Do I > contact one RIR (which maintains a list of other RIR's publication > points) -or- each RIR individually to ask what is their publication > point? (If you can help provide an answer as to what is the > expectation on the operator, I can then potentially help to provide > text). Starting point is most likely one or more Trust Anchor Locator (TAL) files, see draft-ietf-sidr-ta. On that glorious day when the RIRs and IANA have all their ducks in a row, there will be one public TAL for the root of the promised single tree; in the meantime, you'll likely have a small collection of TALs. Where do the TALs come from? Depends on whose TAL it is. Some of the RIRs publish their TALs on their web sites (one RIR, on the other hand, appears to be hiding the TAL for their pilot system in a locked filing cabinet in a disused lavatory in a subbasement with a sign reading "Beware Of Leopard", but that's neither here nor there). Those of us who write RPKI validation software collect these TALs when we can find and verify them, and I, at least, include them with my software. Ultimately, the problem is the same as distributing DNSSEC TAs, or any other TA for that matter. Pretty much by definition, these things have to be configured outside the automated system, because they're the bootstrap data. Inclusion in distributions of software using the system seems to be the most common way, but one could envision other methods (T shirts handed out at IETF or *OG meetings, publication in major newspapers, perhaps as QR codes, invent your own mechanism -- the key point is that grounds for believing the TAL come from outside the system we're trying to bootstrap). From randy@psg.com Mon Nov 14 06:26:41 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36CA21F8E07 for ; Mon, 14 Nov 2011 06:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2aLYDdqMeZd for ; Mon, 14 Nov 2011 06:26:40 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id AFE4121F8E06 for ; Mon, 14 Nov 2011 06:26:40 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RPxUZ-0001Xh-4G; Mon, 14 Nov 2011 14:26:35 +0000 Date: Mon, 14 Nov 2011 22:26:33 +0800 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "Sriram, Kotikalapudi" , sidr wg list Subject: Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 14:26:41 -0000 > It will be as bursty as the sender of the bursts pleases. that is true today, someone can annouce at an arbitrary rate From randy@psg.com Mon Nov 14 06:36:19 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD8411E80C4 for ; Mon, 14 Nov 2011 06:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEKjQlDj5CQp for ; Mon, 14 Nov 2011 06:36:18 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id D5F7411E808D for ; Mon, 14 Nov 2011 06:36:18 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RPxdy-0001ZD-8M; Mon, 14 Nov 2011 14:36:18 +0000 Date: Mon, 14 Nov 2011 22:36:17 +0800 Message-ID: From: Randy Bush To: Shane Amante In-Reply-To: <48A7C4A7-7FFB-44CB-ABCA-76E148AE0574@castlepoint.net> References: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> <48A7C4A7-7FFB-44CB-ABCA-76E148AE0574@castlepoint.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 14:36:19 -0000 > Thanks for the response. I think we're getting closer. See below. i am too stuffed with good food to work tonight. can you catch me in the terminal room tomorrow or whenever. i hang with the rpki interop testing folk. we can talk and hack. randy From brian.peter.dickson@gmail.com Mon Nov 14 07:05:42 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE121F0C6E; Mon, 14 Nov 2011 07:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nO9AGzon0FAC; Mon, 14 Nov 2011 07:05:41 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id F0F5F1F0C6C; Mon, 14 Nov 2011 07:05:37 -0800 (PST) Received: by faap16 with SMTP id p16so1054164faa.31 for ; Mon, 14 Nov 2011 07:05:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BHOWmR/R/A0+LZRUHrTf9+owWTkqOMyboj2Rm0xTBfc=; b=ZFLQGhElcgidxc+TDK5BBesQWdnUHLEZ+IXBiOXDy5SwvRIL31bl2NbNgKKN/Ttb8/ ZyKLwTC+g7r8SSF0ZcicnD5W5vyylDXspKa733PaVDp+WYn9rTqEpgEktjUklXqhoJZN It1Adfa3dxwYfVrxiHyT6w1/p/Kcji/j+Q0Ms= MIME-Version: 1.0 Received: by 10.204.136.211 with SMTP id s19mr12797251bkt.28.1321283137003; Mon, 14 Nov 2011 07:05:37 -0800 (PST) Received: by 10.223.54.15 with HTTP; Mon, 14 Nov 2011 07:05:36 -0800 (PST) In-Reply-To: References: Date: Mon, 14 Nov 2011 10:05:36 -0500 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr-chairs@ietf.org, draft-ietf-sidr-bgpsec-reqs@tools.ietf.org, sidr@ietf.org Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 15:05:42 -0000 On Fri, Oct 28, 2011 at 2:40 PM, Christopher Morrow wrote: > Seems that the authors, at least, expect this doc to be prepared for > WGLC, could we do that concluding 11/11/11 please? Sorry, didn't notice the date in the request. I do have some brief comments about a few bullet points. 3.17 says "no requiring revealing new inter-domain policy info". 3.21 says "don't infer anything regarding intent". 3.22 says "don't trust non-BGPsec markings across trust boundaries". e.g. communities. However (whether this has been acknowledged in the "threat" doc or not), one of the concerns is the ability of BGP speakers, and presumably this will include BGPsec speakers, to manipulate route attributes to attract traffic. Another concern is "route leaks" (which we may not all yet agree on either a definition of, or the scope of what is/isn't a "route leak"). It'd be a long proof to show this, but I believe it is the case that: - route path manipulation (outside of the "expected" paths) can only occur if "route-leak" capabilities exist, i.e. that "route-leaks" are not prevented via some BGPsec mechanisms. Suggestion: A BGPsec design MAY include elements designed to mitigate "route leaks". - (refuting 3.21) This may require marking intent. Suggested text: A BGPsec design MAY require explicit signaling of intent between neighbor ASes, and to "mark" in some limited form, that intent inside a (presumably mandatory) element of a BGPsec design (e.g. via a BGPsec path element). - (leads to negation of 3.17) It MAY be necessary to reveal some aspect of inter-domain policy which can already be accurately inferred via third-party data and tools -- specifically, and limited only, to customer/transit/peer. Additionally: - BGPsec design(s) SHOULD mark attributes used in path selection which are transitive, and MAY mark attributes used in path selection which are non-transitive. (This is necessary for 3.22 to apply and still avoid path manipulation occurring.) Brian From jakob.heitz@ericsson.com Mon Nov 14 07:15:51 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A39A1F0C81 for ; Mon, 14 Nov 2011 07:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFVIcmSwpyVb for ; Mon, 14 Nov 2011 07:15:51 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 01CF91F0C6E for ; Mon, 14 Nov 2011 07:15:50 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAEFFOEd032044; Mon, 14 Nov 2011 09:15:48 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 14 Nov 2011 10:15:40 -0500 From: Jakob Heitz To: Randy Bush Date: Mon, 14 Nov 2011 10:16:22 -0500 Thread-Topic: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs) Thread-Index: Acyi4ERm4I04uc2cSeaDnVDPQLnq4g== Message-ID: References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Sriram, Kotikalapudi" , sidr wg list Subject: Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 15:15:51 -0000 The difference is that today's updates all have the same urgency. BGPSEC is not urgent. It doesn't matter if you don't receive a signature fo= r a few minutes. An UNREACH is not signed. -- Jakob Heitz. On Nov 14, 2011, at 6:26 AM, "Randy Bush" wrote: >> It will be as bursty as the sender of the bursts pleases. >=20 > that is true today, someone can annouce at an arbitrary rate From danny@tcb.net Mon Nov 14 13:38:49 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DC821F8D12 for ; Mon, 14 Nov 2011 13:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwQdZHLDypq0 for ; Mon, 14 Nov 2011 13:38:48 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id E288421F8D4A for ; Mon, 14 Nov 2011 13:38:47 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id E95FB268081; Mon, 14 Nov 2011 14:38:44 -0700 (MST) Received: from [172.16.6.19] (122.147.35.3 [122.147.35.3]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Mon, 14 Nov 2011 14:38:44 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=122.147.35.3; client-port=21250; syn-fingerprint=65535:44:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 From: Danny McPherson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 14 Nov 2011 16:38:42 -0500 Message-Id: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> To: sidr wg list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [sidr] Origin Ops, TALs and Local TAs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 21:38:49 -0000 Rob/Steve, et al., Relative to the SIDR Origin Ops draft and local trust anchor (LTA) configuration, I'm trying to understand how one would actualize trust anchor locators (TALs) and LTAs in a deployment scenario and was hoping you could help me here. I think it's probably safe to assume everyone is going to have a "Constraints" file for some things. Because the TALs don't actually specify the list of resources covered by the referenced self-signed CA certificates the relying party must consult each trust anchor (e.g., RIR) to determine the INR extension(s) within this certificate, and the onus is on the RP to resolve conflicts, is this correct? For example, currently, in the experimental pilot RPKI system many of the INRs are asserting 0.0.0.0/0 and 0::/0, which opens the opportunity for conflicts that must be resolved by the RP, when they likely have no real capability to do this (hence the IAB statement on this topic). Here's my primary question. If I wanted to form a 'federation' of sorts for resiliency would I have to use additional TALs in conjunction with my LTA and paracertificate hierarchy? If so, can an RP include some sort of filter to constrain what a TA can assert as within their resource holdings? That is, because for LTA to work every relying party in the transaction path (i.e., source and destination networks, as well as intermediate RPs) would need to override the putative [global] TA RPKI for every other operators resources and generate a paracertificate hierarchy therein, is that right? And if that's the case, wouldn't it be simpler for RPs to be able to associate resources with each trust anchor rather than trusting them to convey to the RP what resources they are authoritative for? Does this question make sense, or is this problem solved elsewhere? Thanks, -danny From Sandra.Murphy@cobham.com Mon Nov 14 14:08:46 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5578B11E824F for ; Mon, 14 Nov 2011 14:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qe-Vv3z11cZS for ; Mon, 14 Nov 2011 14:08:45 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 005CD11E820F for ; Mon, 14 Nov 2011 14:08:39 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id pAEM8Otd012198 for ; Mon, 14 Nov 2011 16:08:26 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id pAEM8NSX021870 for ; Mon, 14 Nov 2011 16:08:24 -0600 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0339.001; Mon, 14 Nov 2011 17:08:23 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: presentations, jabber scribe and minute taker Thread-Index: Acygsp9Qv7mz9gyGQhaEuo8yB63HNACZyf7p Date: Mon, 14 Nov 2011 22:08:23 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60320F7@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6030A26@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6030A26@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.24] Content-Type: multipart/mixed; boundary="_004_24B20D14B2CD29478C8D5D6E9CBB29F60320F7Hermescolumbiaads_" MIME-Version: 1.0 Subject: [sidr] FW: presentations, jabber scribe and minute taker X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 22:08:46 -0000 --_004_24B20D14B2CD29478C8D5D6E9CBB29F60320F7Hermescolumbiaads_ Content-Type: multipart/alternative; boundary="_000_24B20D14B2CD29478C8D5D6E9CBB29F60320F7Hermescolumbiaads_" --_000_24B20D14B2CD29478C8D5D6E9CBB29F60320F7Hermescolumbiaads_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have had no volunteers to take minutes or serve as jabber scribe. Those= are really needed for the meeting. Please consider volunteering. --Sandy ________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa= ndra [Sandra.Murphy@cobham.com] Sent: Friday, November 11, 2011 3:53 PM To: sidr@ietf.org Subject: [sidr] presentations, jabber scribe and minute taker Those who have slots for presentation at the sidr meeting please send slide= s to both chairs by Tuesday morning. Despite similar requests in the past, we seem to frequently have presentati= ons that show up during the meeting. Please do not do that. Presentations= must be uploaded for everyone to view, especially those who are participat= ing remotely. The chairs may not be able to accommodate your presentation = if it arrives late. We also need a jabber scribe and minute taker. The chairs very much apprec= iate the time and trouble of previous volunteers. Please give thought to d= oing your part this time. (Maybe there should be candy prizes.) Use of the new etherpad collaborative tool for minutes taking is possible i= f any want to try it but is not required. --Sandy, speaking as wg chair --_000_24B20D14B2CD29478C8D5D6E9CBB29F60320F7Hermescolumbiaads_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We have had no volunteers to take minutes or serve as jabber scribe.=   Those are really needed for the meeting.  Please consider volun= teering.

--Sandy

From: sidr-bounces@ietf.org [sidr-bounces@= ietf.org] on behalf of Murphy, Sandra [Sandra.Murphy@cobham.com]
Sent: Friday, November 11, 2011 3:53 PM
To: sidr@ietf.org
Subject: [sidr] presentations, jabber scribe and minute taker

Those who have slots for presentation at the sidr meeting please send slide= s to both chairs by Tuesday morning.

Despite similar requests in the past, we seem to frequently have presentati= ons that show up during the meeting.  Please do not do that.  Pre= sentations must be uploaded for everyone to view, especially those who are = participating remotely.  The chairs may not be able to accommodate your presentation if it arrives late.

We also need a jabber scribe and minute taker.  The chairs very much a= ppreciate the time and trouble of previous volunteers.  Please give th= ought to doing your part this time.  (Maybe there should be candy priz= es.)

Use of the new etherpad collaborative tool for minutes taking is possible i= f any want to try it but is not required.

--Sandy, speaking as wg chair
--_000_24B20D14B2CD29478C8D5D6E9CBB29F60320F7Hermescolumbiaads_-- --_004_24B20D14B2CD29478C8D5D6E9CBB29F60320F7Hermescolumbiaads_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Fri, 11 Nov 2011 20:53:26 GMT"; modification-date="Fri, 11 Nov 2011 20:53:26 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpZHIgbWFp bGluZyBsaXN0DQpzaWRyQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NpZHINCg== --_004_24B20D14B2CD29478C8D5D6E9CBB29F60320F7Hermescolumbiaads_-- From danny@tcb.net Mon Nov 14 14:57:43 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3361C1F0CAC for ; Mon, 14 Nov 2011 14:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yeAkUJir-JA for ; Mon, 14 Nov 2011 14:57:42 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id BA5171F0C77 for ; Mon, 14 Nov 2011 14:57:40 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 7D665268081; Mon, 14 Nov 2011 15:57:40 -0700 (MST) Received: from [172.16.6.19] (122.147.35.3 [122.147.35.3]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 14 Nov 2011 15:57:40 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=122.147.35.3; client-port=17212; syn-fingerprint=65535:44:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <20111114133704.72C05654865@minas-ithil.hactrn.net> Date: Mon, 14 Nov 2011 17:57:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <45A556D4-F367-4193-A418-7993AF42A0EC@tcb.net> References: <805B0799-7026-4532-A53C-4CFE3E863A33@castlepoint.net> <48A7C4A7-7FFB-44CB-ABCA-76E148AE0574@castlepoint.net> <20111114133704.72C05654865@minas-ithil.hactrn.net> To: Rob Austein X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] WGLC: draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 22:57:43 -0000 On Nov 14, 2011, at 8:37 AM, Rob Austein wrote: > Ultimately, the problem is the same as distributing DNSSEC TAs, or any > other TA for that matter. Pretty much by definition, these things > have to be configured outside the automated system, because they're > the bootstrap data. Inclusion in distributions of software using the > system seems to be the most common way, but one could envision other > methods (T shirts handed out at IETF or *OG meetings, publication in > major newspapers, perhaps as QR codes, invent your own mechanism -- > the key point is that grounds for believing the TAL come from outside > the system we're trying to bootstrap). However, in the interim (until we have a single RPKI root), the = origin-ops=20 draft should provide some guidance about how an RP should have the=20 capability to verify "look-aside" (ugh) what resources an "INR" holds, = and=20 recommend that they only accept associated RPKI data for those=20 resources. The onus cannot be on the RP to resolve this themselves at=20= on a global scale. The model where each of the TAs in the TAL can assert what it is they're=20= authoritative for is even mode broken than the browser/SSL/CA issues=20 that we're trying to fix with DANE (the attacker at least has to be = on-path=20 there, before they consult a compromised CA). Furthermore, pending the outcome of the discussion in the other thread I started related to this topic and local TAs, the origin-ops draft = should also=20 include some discussion about multiple parties involved in LTA-esque=20 functions (or extra TALs with "constraints") to preserve inter-domain=20 connectivity during putative RPKI override/bypass functions for source,=20= destination, and intermediate networks. -danny =20= From sra@hactrn.net Mon Nov 14 15:48:06 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B833E21F8663 for ; Mon, 14 Nov 2011 15:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.066 X-Spam-Level: X-Spam-Status: No, score=-102.066 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHcQVZrWSfg6 for ; Mon, 14 Nov 2011 15:48:06 -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 6DB7B21F853A for ; Mon, 14 Nov 2011 15:48:03 -0800 (PST) Received: from minas-ithil.hactrn.net (dhcp-45b6.meeting.ietf.org [130.129.69.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 687B928465 for ; Mon, 14 Nov 2011 23:47:57 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 33CA96550DD for ; Tue, 15 Nov 2011 07:47:54 +0800 (CST) Date: Tue, 15 Nov 2011 07:47:54 +0800 From: Rob Austein To: sidr@ietf.org In-Reply-To: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> References: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20111114234754.33CA96550DD@minas-ithil.hactrn.net> Subject: Re: [sidr] Origin Ops, TALs and Local TAs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 23:48:06 -0000 Danny, For purposes of this discussion, a LTA is semantically equivalent to a collection of TAs plus a constraint list. Since LTAs are also a more general mechanism (they can be shared by a group of like-minded folks more easily than a constraint list -- just create a TAL pointing at the LTA) and since LTAs have the nice property of keeping the raw constraint list out of the validator itself (thus keeping the validator that much simpler), my advice to anybody who thinks they need a constraint list would be to use a LTA. We can discuss this further at the face to face meeting if you like, but that's the summary as I see it at the technical layer. Layers 8+ are mostly out of scope for this list, so let me just say that I am really hoping that IANA and the RIRs will get their collective act together and issue a single TA before this becomes a serious problem. They say that they intend to do so. As somebody (KC Claffy?) said a few years ago, relying parties should not have to sort out this mess, that's what the industry pays the RIRs to do. For the moment I'm willing to take the RIRs' word that they intend to do their job and just need a bit more time. YMMV. If that fails, well, maybe we can talk to Olaf Kolkman about having his friend Bert sign the RPKI root. This isn't rocket science. From Sandra.Murphy@cobham.com Mon Nov 14 16:01:27 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA6A21F8E31 for ; Mon, 14 Nov 2011 16:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6HqKGXhhI8E for ; Mon, 14 Nov 2011 16:01:27 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id E9D5321F8E21 for ; Mon, 14 Nov 2011 16:01:23 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id pAF00wgm013642 for ; Mon, 14 Nov 2011 18:01:04 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id pAF00wid025392 for ; Mon, 14 Nov 2011 18:00:58 -0600 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0339.001; Mon, 14 Nov 2011 19:00:45 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: some sidr "replaced by" cleanup Thread-Index: AQHMov2LD+q/hFx1S0S3QVzGLNumMQ== Date: Tue, 15 Nov 2011 00:00:44 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6031B4D@Hermes.columbia.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.24] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] some sidr "replaced by" cleanup X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 00:01:27 -0000 I'm about to request some cleanup of the draft "replaced by" relationships.= If you see anything incorrect about the list below, please let me know.= =0A= =0A= =0A= The tools page already records some of these "replaced by" records. Howeve= r, the datatracker is authoritative and the datatracker has not caught some= of what the tools site records.=0A= =0A= =0A= This draft Should be replaced by = this draft =0A= draft-rgaglian-sidr-algorithm-agility draft-ietf-sidr-algorithm-agility= =0A= draft-turner-sidr-bgpsec-algs draft-ietf-sidr-bgpsec-algs =0A= draft-ymbk-bgpsec-ops draft-ietf-sidr-bgpsec-ops =0A= draft-lepinski-bgpsec-overview draft-ietf-sidr-bgpsec-overview = =0A= draft-turner-sidr-bgpsec-pki-profiles draft-ietf-sidr-bgpsec-pki-profiles= =0A= draft-lepinski-bgpsec-protocol draft-ietf-sidr-bgpsec-protocol = =0A= draft-ymbk-bgpsec-reqs draft-ietf-sidr-bgpsec-reqs =0A= draft-kent-bgpsec-threats draft-ietf-sidr-bgpsec-threats = =0A= draft-manderson-iana-objects draft-ietf-sidr-iana-objects =0A= =0A= --Sandy, speaking as wg chair=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= From danny@tcb.net Mon Nov 14 16:02:29 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4188911E8095 for ; Mon, 14 Nov 2011 16:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xk1AmglAMzSz for ; Mon, 14 Nov 2011 16:02:28 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id BB44811E8090 for ; Mon, 14 Nov 2011 16:02:28 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 7C492268081; Mon, 14 Nov 2011 17:02:28 -0700 (MST) Received: from dhcp-1267.meeting.ietf.org (dhcp-1267.meeting.ietf.org [130.129.18.103]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 14 Nov 2011 17:02:27 -0700 (MST) (envelope-from danny@tcb.net) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <20111114234754.33CA96550DD@minas-ithil.hactrn.net> Date: Mon, 14 Nov 2011 19:02:09 -0500 Content-Transfer-Encoding: 7bit Message-Id: <87819BD9-1829-438C-A479-A315819943D0@tcb.net> References: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> <20111114234754.33CA96550DD@minas-ithil.hactrn.net> To: Rob Austein X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] Origin Ops, TALs and Local TAs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 00:02:29 -0000 On Nov 14, 2011, at 6:47 PM, Rob Austein wrote: > Danny, > > For purposes of this discussion, a LTA is semantically equivalent to a > collection of TAs plus a constraint list. Since LTAs are also a more > general mechanism (they can be shared by a group of like-minded folks > more easily than a constraint list -- just create a TAL pointing at > the LTA) and since LTAs have the nice property of keeping the raw > constraint list out of the validator itself (thus keeping the > validator that much simpler), my advice to anybody who thinks they > need a constraint list would be to use a LTA. > > We can discuss this further at the face to face meeting if you like, > but that's the summary as I see it at the technical layer. That'd be good, because I'm not comfortable with that as an RP. > Layers 8+ are mostly out of scope for this list, so let me just say > that I am really hoping that IANA and the RIRs will get their > collective act together and issue a single TA before this becomes a > serious problem. They say that they intend to do so. As somebody (KC > Claffy?) said a few years ago, relying parties should not have to sort > out this mess, that's what the industry pays the RIRs to do. For the > moment I'm willing to take the RIRs' word that they intend to do their > job and just need a bit more time. YMMV. Until then (or even after in the event of a CA compromise), it's a technical issue and the capability for RPs to determine who holds what resources, or at least to constrain who they trust with what resources, and intersect that with the LTA 'federation' issue is very much an operational issue. -danny From Sandra.Murphy@cobham.com Mon Nov 14 16:03:46 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5EA411E80A3 for ; Mon, 14 Nov 2011 16:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSj1Ot8+YKMn for ; Mon, 14 Nov 2011 16:03:45 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id DF36811E809B for ; Mon, 14 Nov 2011 16:03:42 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id pAF0302s013660 for ; Mon, 14 Nov 2011 18:03:11 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id pAF02xVW025455 for ; Mon, 14 Nov 2011 18:03:00 -0600 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0339.001; Mon, 14 Nov 2011 19:02:59 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: presentations Thread-Index: AcyjGbm8Xdu7F8FNQfGUyR1sBVYpRQ== Date: Tue, 15 Nov 2011 00:02:59 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60320F3@Hermes.columbia.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.24] Content-Type: multipart/alternative; boundary="_000_24B20D14B2CD29478C8D5D6E9CBB29F60320F3Hermescolumbiaads_" MIME-Version: 1.0 Subject: [sidr] presentations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 00:03:47 -0000 --_000_24B20D14B2CD29478C8D5D6E9CBB29F60320F3Hermescolumbiaads_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have uploaded all the slide sets (all four of them) received - for the mi= b draft, the pfx-validate draft, the router cert profile and algorithms, an= d the cpu load analysis. If you think you have sent slides and do not see your slides listed, or wha= t is uploaded is not what you want there, please let the chairs know as soo= n as possible. Those who have not yet sent slides to the chairs - it would be really good = to do that soon. --Sandy, speaking as wg chair --_000_24B20D14B2CD29478C8D5D6E9CBB29F60320F3Hermescolumbiaads_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have uploaded all the slide sets (all four of them) received - for= the mib draft, the pfx-validate draft, the router cert profile and algorit= hms, and the cpu load analysis.

If you think you have sent slides and do not see your slides listed, or wha= t is uploaded is not what you want there, please let the chairs know as soo= n as possible.

Those who have not yet sent slides to the chairs - it would be really good = to do that soon.

--Sandy, speaking as wg chair


--_000_24B20D14B2CD29478C8D5D6E9CBB29F60320F3Hermescolumbiaads_-- From wesley.george@twcable.com Mon Nov 14 17:37:03 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A7221F8E80 for ; Mon, 14 Nov 2011 17:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.765 X-Spam-Level: X-Spam-Status: No, score=-0.765 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uijBEtISNqDq for ; Mon, 14 Nov 2011 17:37:03 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id E381F21F8E7F for ; Mon, 14 Nov 2011 17:37:02 -0800 (PST) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,511,1315195200"; d="scan'208";a="297386228" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 14 Nov 2011 20:32:32 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Mon, 14 Nov 2011 20:37:00 -0500 From: "George, Wes" To: Jakob Heitz , Randy Bush Date: Mon, 14 Nov 2011 20:37:24 -0500 Thread-Topic: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs) Thread-Index: Acyi4ERm4I04uc2cSeaDnVDPQLnq4gAVRYNQ Message-ID: References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Sriram, Kotikalapudi" , sidr wg list Subject: Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 01:37:03 -0000 > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Jakob Heitz > > The difference is that today's updates all have the same urgency. > BGPSEC is not urgent. It doesn't matter if you don't receive a > signature for a few minutes. > An UNREACH is not signed. [WEG] I don't totally agree with this characterization. If the BGPSec info = triggers a recalculation of bestpath from what was chosen when the unsigned= update came through, this has the potential to drive 2x the work, essentia= lly take 2x longer for convergence, plus push another round of updates to d= ownstream neighbors, another reprogram of the FIB, etc. Seems to me by the = time we've gained any benefit of saving updates for later because the box i= s busy, we've triggered a far worse potential death spiral on a busy box. P= rocessing a few additional updates is rather pale in comparison to having t= o consistently recalculate a non-trivial percentage of the table when the b= ox gets "busy." Similar to buffering and QoS, you can't get something for nothing here, and= there are limits to where deferred processing can help to smooth out peaks= vs. simply throwing more capacity at the problem, especially in the land o= f often underutilized multi-core systems. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From jakob.heitz@ericsson.com Mon Nov 14 17:46:52 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4D511E81FC for ; Mon, 14 Nov 2011 17:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.205 X-Spam-Level: X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oALirbmGqz5Z for ; Mon, 14 Nov 2011 17:46:51 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 950D811E81F6 for ; Mon, 14 Nov 2011 17:46:51 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAF1kmpt020608; Mon, 14 Nov 2011 19:46:50 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 14 Nov 2011 20:46:44 -0500 From: Jakob Heitz To: "George, Wes" , Randy Bush Date: Mon, 14 Nov 2011 20:46:42 -0500 Thread-Topic: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs) Thread-Index: Acyi4ERm4I04uc2cSeaDnVDPQLnq4gAVRYNQAACGhYA= Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Sriram, Kotikalapudi" , sidr wg list Subject: Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 01:46:52 -0000 I can not believe that it will be 2X. First case: A beacon will very rarely cause a different bestpath. Second case: There is actually a changed route being updated. You will receive both a regular update and a signature. Only one of those will casue a new bestpath in the great majority of cases. Basically, in the large majority of cases, a signature does not change the bestpath. -- Jakob Heitz. > -----Original Message----- > From: George, Wes [mailto:wesley.george@twcable.com] > Sent: Monday, November 14, 2011 5:37 PM > To: Jakob Heitz; Randy Bush > Cc: Sriram, Kotikalapudi; sidr wg list > Subject: RE: [sidr] Burstiness of BGP updates (was: WGLC: draft- > ietf-sidr-bgpsec-reqs) >=20 > > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On > Behalf > > Of Jakob Heitz > > > > The difference is that today's updates all have the same urgency. > > BGPSEC is not urgent. It doesn't matter if you don't receive a > > signature for a few minutes. > > An UNREACH is not signed. >=20 > [WEG] I don't totally agree with this characterization. If the > BGPSec info triggers a recalculation of bestpath from what was > chosen when the unsigned update came through, this has the potential > to drive 2x the work, essentially take 2x longer for convergence, > plus push another round of updates to downstream neighbors, another > reprogram of the FIB, etc. Seems to me by the time we've gained any > benefit of saving updates for later because the box is busy, we've > triggered a far worse potential death spiral on a busy box. > Processing a few additional updates is rather pale in comparison to > having to consistently recalculate a non-trivial percentage of the > table when the box gets "busy." > Similar to buffering and QoS, you can't get something for nothing > here, and there are limits to where deferred processing can help to > smooth out peaks vs. simply throwing more capacity at the problem, > especially in the land of often underutilized multi-core systems. >=20 > Wes George >=20 > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or > subject to copyright belonging to Time Warner Cable. This E-mail is > intended solely for the use of the individual or entity to which it > is addressed. If you are not the intended recipient of this E-mail, > you are hereby notified that any dissemination, distribution, > copying, or action taken in relation to the contents of and > attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any > copy of this E-mail and any printout. From danny@tcb.net Mon Nov 14 18:12:33 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2070321F8D45 for ; Mon, 14 Nov 2011 18:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsAoqqErtsiI for ; Mon, 14 Nov 2011 18:12:32 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 9969C21F8D44 for ; Mon, 14 Nov 2011 18:12:32 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 5A2E2268063; Mon, 14 Nov 2011 19:12:32 -0700 (MST) Received: from dhcp-1267.meeting.ietf.org (dhcp-1267.meeting.ietf.org [130.129.18.103]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Mon, 14 Nov 2011 19:12:32 -0700 (MST) (envelope-from danny@tcb.net) From: Danny McPherson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Nov 2011 21:12:13 -0500 Message-Id: <74F0D6F4-EA7B-4B2E-B195-D34448CD4CDF@tcb.net> To: sidr wg list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [sidr] Comment on draft-ietf-sidr-origin-validation-signaling-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:12:33 -0000 In general, I don't like the idea of using an extcomm community to = convey=20 a prefixes validation state, I think we should deal with this problem = natively=20 (e.g., as BGPSEC inter-domain) if we're going to address the problem, in particular if we're not going to address the AS Confederations problem. Furthermore, I don't like the deployment considerations, in particular = because=20 of "privilege escalation attacks" which could easily occur through = misconfiguration=20 across multiple attribute mapping functions, or simply because the = extcomm was received from an BGP peer that isn't "upgraded to support the extensions=20= defined in this document": "In deployment scenarios where not all the speakers in an autonomous system are upgraded to support the extensions defined in this document, it is necessary to define policies that match on the origin validation extended community and set another BGP attribute [I-D.ietf-sidr-pfx-validate] that influences the best path selection the same way as what would have been enabled by an implementation of this extension." Finally, this should certainly a normative reference in the pfx-validate = draft. -danny= From Sandra.Murphy@cobham.com Mon Nov 14 18:56:51 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051631F0D61 for ; Mon, 14 Nov 2011 18:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRaDLE36+kc1 for ; Mon, 14 Nov 2011 18:56:50 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 35B271F0D53 for ; Mon, 14 Nov 2011 18:56:49 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id pAF2uO0M024864 for ; Mon, 14 Nov 2011 20:56:29 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id pAF2uNBK016809 for ; Mon, 14 Nov 2011 20:56:24 -0600 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0339.001; Mon, 14 Nov 2011 21:56:23 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 Thread-Index: AQHMnxsyCx2p0PZ7Tu6Ty5HU0UcysZWnVAyUgAXuq28= Date: Tue, 15 Nov 2011 02:56:22 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F603227E@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6025FEE@Hermes.columbia.ads.sparta.com> , , <24B20D14B2CD29478C8D5D6E9CBB29F6028DB8@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6028DB8@Hermes.columbia.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.24] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:56:51 -0000 One clarification. I included Eric below as he was one of those who took o= ffense at the conclusion Steve drew from Brian's remark about colleagues. = Unfortunately, "you" is both singular and plural, so the text as written im= plies that Eric colluded in the remark about "colleagues". I should defini= tely have said "If Brian meant".=0A= =0A= --Sandy, to clarify my previous speaking as wg chair=0A= =0A= ________________________________________=0A= From: Murphy, Sandra=0A= Sent: Friday, November 11, 2011 3:47 PM=0A= To: Brian Dickson; Stephen Kent=0A= Cc: sidr@ietf.org=0A= Subject: RE: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03=0A= =0A= Guys, guys, guys.=0A= =0A= Steve: making reference to a person's company concentrates too much on the = personal. Please be more careful.=0A= =0A= Brian, Eric: If you meant "some individual contributors who I happen to k= now and discuss this with", saying "my colleagues" was subject to misinterp= retation, especially in light of this recent energetic exchange.=0A= =0A= --Sandy, speaking out for civility as wg chair=0A= =0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Eric Oster= weil [eosterweil@verisign.com]=0A= Sent: Thursday, November 10, 2011 11:17 AM=0A= To: Stephen Kent=0A= Cc: sidr@ietf.org list=0A= Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03=0A= =0A= On Nov 9, 2011, at 1:42 PM, Stephen Kent wrote:=0A= =0A= > At 1:27 AM -0500 11/8/11, Brian Dickson wrote:=0A= >> ...=0A= >=0A= >> I do not support adoption of this document in its current form.=0A= >>=0A= >> The main reasons have to do with fundamental aspects which at a high=0A= >> level have been addressed by my colleagues,=0A= >=0A= > so, this is a Verisign critique, provided by you, Eric, and Danny?=0A= =0A= Steve,=0A= =0A= This is a ridiculous question, and the implication is a completely false ch= aracterization of my involvement. For the record: I am participating as an= individual only.=0A= =0A= Eric=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Brian Dick= son [brian.peter.dickson@gmail.com]=0A= Sent: Wednesday, November 09, 2011 3:07 PM=0A= To: Stephen Kent=0A= Cc: sidr@ietf.org=0A= Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03=0A= =0A= On Wed, Nov 9, 2011 at 1:42 PM, Stephen Kent wrote:=0A= > At 1:27 AM -0500 11/8/11, Brian Dickson wrote:=0A= >=0A= > ...=0A= >=0A= > I do not support adoption of this document in its current form.=0A= >=0A= > The main reasons have to do with fundamental aspects which at a high=0A= >=0A= > level have been addressed by my colleagues,=0A= >=0A= > so, this is a Verisign critique, provided by you, Eric, and Danny?=0A= =0A= Respectfully, Stephen, I would ask that you not infer anything along=0A= these lines.=0A= The IETF is very clear on participation being an individual activity,=0A= regardless of=0A= $day_job.=0A= =0A= In addition to this _not_ being the case, I _personally_ consider this both= =0A= highly inappropriate at a professional level, and bordering on _ad_hominem_= ,=0A= something that really has no place in WG mailing-list discussions.=0A= =0A= I would ask that you seriously consider whether an apology for your comment= =0A= is appropriate.=0A= =0A= As for "colleague", I meant within the WG, as in "collegial". If I had mean= t to=0A= say "co-worker", I would have said "co-worker".=0A= =0A= Any similarity between our concerns is entirely due to similarity in operat= ional=0A= experiences in a variety of venues, at a variety of $day_jobs.=0A= =0A= I'll address the content-oriented portion of your email in a separate messa= ge.=0A= =0A= Brian=0A= - not using any email-address that would suggest affiliation -=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From kent@bbn.com Mon Nov 14 18:58:58 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414F81F0C9F for ; Mon, 14 Nov 2011 18:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.528 X-Spam-Level: X-Spam-Status: No, score=-106.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EE2EF8UJY5v7 for ; Mon, 14 Nov 2011 18:58:57 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 01FA11F0C8F for ; Mon, 14 Nov 2011 18:58:57 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:45538 helo=[172.20.1.65]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RQ9Eb-000Lm4-63; Mon, 14 Nov 2011 21:58:56 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> <3F1388E3-A694-42C9-AE2F-F12BF15DC86F@verisign.com> Date: Mon, 14 Nov 2011 21:53:22 -0500 To: Eric Osterweil From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-890796563==_ma============" Cc: "sidr@ietf.org list" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:58:58 -0000 --============_-890796563==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Eric, i think we are making progress. thanks for the feedback. >... > >I really think we should address these issues in a single document. >It seems like splitting this off into a separate/as yet unwritten >document is likely to cause some problems. In particular, since >that document does not yet exist, and it may not be written and >adopted for some time, this draft will not be complete on its own. >I'm worried that it is hard to judge this document's readiness w/o >these timeline issues worked out or even broached (as they may >demand changes to this process). Besides, isn't the corpus of >drafts rather extensive already (w/o adding another)? :) My motivation for a separate timetable (vs. timeline) doc is that there seems to be some agreement that this doc should be a product of the operator community. The alg transition doc is an IETF architectural statement, the product of this WG. I can't see combining the two. Did I misunderstand your concern here? >... > >OK, I see. But, aren't there second-order effects of this that we >have to worry about? For example, if I am an ISP whose CA performs >the rollover properly, but my upstream's CA does not, then their >CA's failure to keep up will cause my ISP to no longer be able to >participate in BGPsec, right (because I'm no longer part of a >contiguous BGPsec island)? I realize this is a bit different than >my original example, but upon thinking about the motivation for my >comment, my point was more general. It was that transitioning a CA >to this state can have very undesirable effects. What you say that you performed the rollover but the CA above you didn't can you be more specific, re the phase number? >s/I envision/we envision/ fixed >kewl, thnx. One minor nit: can we rephrase one part for clarity. >Instead of "If a problem arises that makes this infeasible for a >substantial number of CAs," can we just specify a little bit about >how this is determined. Maybe something like, "If operational governing body we elect for timeline statements> deems a >problem to have arisen that is significant enough to make this >infeasible for a significant enough number of CAs..." Good suggestion. I had already changed the text to the following form. If it is determined that a substantial number of CAs are unable Since we don't have a good placeholder for the bracketed entity I think it's easier to make the statement without say who makes the determination. >... > >First, same minor nit as above. >Second, do we want to consider the case were we want to rollback >(perhaps an alg B has become unsuitable for some reason and we need >to choose a new alg B altogether)? I'm not saying the above text >should be yanked, maybe just augmented? AI had not considered the case of an alg concern at this phase, Good catch. I'll add suitable text to Phases 1-4. >... > >I think this is a very strange comment (and I note that you said it >earlier in this email too). "Use of the RPKI... is optional." Is >the goal of this system to protect the global routing infrastructure >or not? The goal of this work does not imply that we can force all ISPs to adopt it. We hope that the RPKI will be very widely deployed and used, but we acknowledge that it may not me universal. So, both initially and perhaps forever, the world will consist of resources that are protected by certs and ROAs, and ones that are not. > Unless we are talking about making this an experimental >expedition, and are prepared to create a globally applicable system >later? that's not a sentence :-). > If the goal is to secure the global routing system (note I am not >saying universal deployment in the foreseeable future, just global >applicability), then this is an operational non-starter. I'm glad that we agree that universal deployment is not a likely near term event. We also agree that the RPKI is globally applicable . Neitehr of these observations conflict with the fact that its use by an network operator is optional. > I do not believe it is appropriate for us to try and re-legislate >operational axioms in these drafts. What we could be doing is >grossly misaligning this standards work with operational invariants. I no longer know what you are referring to. I have said that we cannot mandate adherence to this process. We can offer it as a preferred approach and hope that it is followed. We have incorporated a number of phases so that there is an opportunity to verify the status of the transition, and to allow the timeline to be pushed back if necessary. if what you are saying is that we ought not specify any process that calls for CAs and RPs to try to execute a transition in a coordinated fashion, over a long time interval, then we have an impasse. The disagreement is based on perceptions, on both of our parts, not facts. > > First, not that a CA cannot unilaterally decide to transition to >a new algorithm. There is a requirement that the issuer of its >certificate is prepared to accept a certificate request under the >new algorithm suite (because of the PoP requirement). > >I'm sorry, I don't understand. PoP requires the issue of a cert to verify that the cert requester posses the private key corresponding to the public key in the cert request. So, if CA N requests a cert that contains a key under Alg X, CA N-1 (its parent ) cannot issue that cert until CA N-1 has implemented Alg X. Does this help? >... > >> To avoid more flame wars, I will duck your question about my views >>on DNSSEC and accommodation of different algorithm suites :-). > >Shall I take that as a retraction of your comment? ;) no. Steve --============_-890796563==_ma============ Content-Type: text/html; charset="us-ascii" Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03
Eric,

i think we are making  progress. thanks for the feedback.

...

I really think we should address these issues in a single document.  It seems like splitting this off into a separate/as yet unwritten document is likely to cause some problems.  In particular, since that document does not yet exist, and it may not be written and adopted for some time, this draft will not be complete on its own.  I'm worried that it is hard to judge this document's readiness w/o these timeline issues worked out or even broached (as they may demand changes to this process).  Besides, isn't the corpus of drafts rather extensive already (w/o adding another)? :)

My motivation for a separate timetable (vs. timeline) doc is that there seems to be some agreement that this doc should be a product of the operator community. The alg transition doc is an IETF architectural statement, the product of this WG. I can't see combining the two.  Did I misunderstand your concern here?

...

OK, I see.  But, aren't there second-order effects of this that we have to worry about?  For example, if I am an ISP whose CA performs the rollover properly, but my upstream's CA does not, then their CA's failure to keep up will cause my ISP to no longer be able to participate in BGPsec, right (because I'm no longer part of a contiguous BGPsec island)?  I realize this is a bit different than my original example, but upon thinking about the motivation for my comment, my point was more general.  It was that transitioning a CA to this state can have very undesirable effects.

What you say that you performed the rollover but the CA above you didn't can you be more specific, re the phase number?

s/I envision/we envision/

fixed

kewl, thnx.  One minor nit: can we rephrase one part for clarity.  Instead of "If a problem arises that makes this infeasible for a substantial number of CAs," can we just specify a little bit about how this is determined.  Maybe something like, "If <whoever the operational governing body we elect for timeline statements> deems a problem to have arisen that is significant enough to make this infeasible for a significant enough number of CAs..."

Good suggestion. I had already changed the text to the following form.

If it is determined that a substantial number of CAs are unable

Since we don't have a good placeholder for the bracketed entity I think it's easier to make the statement without say who makes the determination.
...

First, same minor nit as above.
Second, do we want to consider the case were we want to rollback (perhaps an alg B has become unsuitable for some reason and we need to choose a new alg B altogether)?  I'm not saying the above text should be yanked, maybe just augmented?

AI had not considered the case of an alg concern at this phase,  Good catch. I'll add suitable text to Phases 1-4.

...

I think this is a very strange comment (and I note that you said it earlier in this email too).  "Use of the RPKI... is optional."  Is the goal of this system to protect the global routing infrastructure or not?

The goal of this work does not imply that we can force all ISPs to adopt it.  We hope that the RPKI will be very widely deployed and used, but we acknowledge that it may not me universal. So, both initially and perhaps forever, the world will consist of resources that are protected by certs and ROAs, and ones that are not.

  Unless we are talking about making this an experimental expedition, and are prepared to create a globally applicable system later?

that's not a sentence :-).
  If the goal is to secure the global routing system (note I am not saying universal deployment in the foreseeable future, just global applicability), then this is an operational non-starter.

I'm glad that we agree that universal deployment is not a likely near term event. We also agree that the RPKI is globally applicable . Neitehr of these observations conflict with the fact that its use by an network operator is optional.

  I do not believe it is appropriate for us to try and re-legislate operational axioms in these drafts.  What we could be doing is grossly misaligning this standards work with operational invariants.

I no longer know what you are referring to. I have said that we cannot mandate adherence to this process.  We can offer it as a preferred approach and hope that it is followed. We have incorporated a number of phases so that there is an opportunity to verify the status of the transition, and to allow the timeline to be pushed back if necessary. if what you are saying is that we ought not specify any process that calls for CAs and RPs to try to execute a transition in a coordinated fashion, over a long time interval, then we have an impasse. The disagreement is based on perceptions, on both of our parts, not facts.

> First, not that a CA cannot unilaterally decide to transition to a new algorithm. There is a requirement that the issuer of its certificate is prepared to accept a certificate request under the new algorithm suite (because of the PoP requirement).

I'm sorry, I don't understand.

PoP requires the issue of a cert to verify that the cert requester posses the private key corresponding to the public key in the cert request. So, if CA N requests a cert that contains a key under Alg X, CA N-1 (its parent ) cannot issue that cert until CA N-1 has implemented Alg X. Does this help?

...

> To avoid more flame wars, I will duck your question about my views on DNSSEC and accommodation of different algorithm suites :-).
Shall I take that as a retraction of your comment? ;)

no.

Steve
--============_-890796563==_ma============-- From wesley.george@twcable.com Mon Nov 14 19:03:33 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1E11F0D92 for ; Mon, 14 Nov 2011 19:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.774 X-Spam-Level: X-Spam-Status: No, score=-0.774 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPwrAhBiBsqw for ; Mon, 14 Nov 2011 19:03:33 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0B41F0D8E for ; Mon, 14 Nov 2011 19:03:33 -0800 (PST) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,511,1315195200"; d="scan'208";a="297399594" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 14 Nov 2011 21:58:56 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Mon, 14 Nov 2011 22:03:24 -0500 From: "George, Wes" To: Jakob Heitz , Randy Bush Date: Mon, 14 Nov 2011 22:03:49 -0500 Thread-Topic: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs) Thread-Index: Acyi4ERm4I04uc2cSeaDnVDPQLnq4gAVRYNQAACGhYAAApkZwA== Message-ID: References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Sriram, Kotikalapudi" , sidr wg list Subject: Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 03:03:34 -0000 > From: Jakob Heitz [mailto:jakob.heitz@ericsson.com] > Sent: Monday, November 14, 2011 8:47 PM > To: George, Wes; Randy Bush > Cc: Sriram, Kotikalapudi; sidr wg list > Subject: RE: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf- > sidr-bgpsec-reqs) > > I can not believe that it will be 2X. [WEG] the objective amount of impact is probably not the important bit here= . > > First case: A beacon will very rarely cause a different bestpath. [WEG] True. However... your comment was not specific to beacons. Also when = it does, it makes the load problem you're trying to solve worse. > > Second case: There is actually a changed route being updated. > You will receive both a regular update and a signature. > Only one of those will casue a new bestpath in the great majority of > cases. > > Basically, in the large majority of cases, a signature does not change > the bestpath. > [WEG] Not true. Bestpath in BGPSec land is chosen based on policy informed = by the difference between valid, invalid and unknown. Even if the absence o= r presence of the signature only toggles the route between valid and unknow= n, given that those have a defined policy action (eg raise or lower local p= ref, etc), the only way to ensure that receiving a signature later than the= initial route update does not trigger a change of best path (let alone a r= ecompute that doesn't trigger a change, which probably has nearly the same = impact) is to set ones policy such that unknown and valid are the same pref= erence. While that may be reasonable in early incremental deployment, event= ually I don't think that's a safe assumption, and really eventually is when= we have a scaling problem, not in early deployment. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From christopher.morrow@gmail.com Mon Nov 14 19:07:05 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8D71F0C98 for ; Mon, 14 Nov 2011 19:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.543 X-Spam-Level: X-Spam-Status: No, score=-103.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3WTqO-ojYNs for ; Mon, 14 Nov 2011 19:07:04 -0800 (PST) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 525E71F0C92 for ; Mon, 14 Nov 2011 19:07:04 -0800 (PST) Received: by pzk5 with SMTP id 5so11528900pzk.9 for ; Mon, 14 Nov 2011 19:07:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eah/UpdEXYy+NMfY/cCHMlPDPB3n20yJ9hG2VtjQulY=; b=uw63ALYKxdDiYRiGZ+cxT99w4zHfHsdtm6WSwXd5EGvehQW4roc6wcHK9CVDqgv5e3 Nrcan09y50lGjIi0bqmBF0o9E/7L8JwR9zHjLTm9x6OB3vCfQbndrSN2u3N/S/O/lmb2 gAY5rRVXM2lA/fw4Oh2VpYb+X8tw83sp/pWwc= MIME-Version: 1.0 Received: by 10.68.5.162 with SMTP id t2mr56237948pbt.73.1321326423849; Mon, 14 Nov 2011 19:07:03 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.68.63.230 with HTTP; Mon, 14 Nov 2011 19:07:03 -0800 (PST) In-Reply-To: <87819BD9-1829-438C-A479-A315819943D0@tcb.net> References: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> <20111114234754.33CA96550DD@minas-ithil.hactrn.net> <87819BD9-1829-438C-A479-A315819943D0@tcb.net> Date: Mon, 14 Nov 2011 22:07:03 -0500 X-Google-Sender-Auth: LE919rvclnPaNz6YcgDdY7wEMkk Message-ID: From: Christopher Morrow To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rob Austein , sidr@ietf.org Subject: Re: [sidr] Origin Ops, TALs and Local TAs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 03:07:05 -0000 On Mon, Nov 14, 2011 at 7:02 PM, Danny McPherson wrote: > > On Nov 14, 2011, at 6:47 PM, Rob Austein wrote: > >> Layers 8+ are mostly out of scope for this list, so let me just say >> that I am really hoping that IANA and the RIRs will get their >> collective act together and issue a single TA before this becomes a >> serious problem. =A0They say that they intend to do so. =A0As somebody (= KC >> Claffy?) said a few years ago, relying parties should not have to sort >> out this mess, that's what the industry pays the RIRs to do. =A0For the >> moment I'm willing to take the RIRs' word that they intend to do their >> job and just need a bit more time. =A0YMMV. > > Until then (or even after in the event of a CA compromise), it's a > technical issue and the capability for RPs to determine who holds > what resources, or at least to constrain who they trust with what > resources, and intersect that with the LTA 'federation' issue is very > much an operational issue. This is back to your (danny) point about: If someone[1] removes a Resource Certification (ROA, for instance) and that resource is actually critical[2] (or in use), all parties between the resource (server) and the service-requestor (user) are bound to need to know that the resource is still there, and valid. These parties all need to populate their LTA (Local Trust Anchor) with the right certification data. This seems like it will be messy, telling everyone via some phone-tree, and potentially confusing. On top of that if the resource is then re-certified (to the same or different end entity) how do the intermediate parties know which is the 'right' thing to do? -chris [1]: This is the nominal 'black helicopters' problem, also seen today via ICE or PROTECT-IP [2]: The netblock, for instance, for the .cx ccTLD (presuming that .cx is doing/permitting-some-actions that a third party finds objectionable) b: I made up the example, and the 2 'black helicopter' examples are certainly USA-centric, we could make up many more, but ... that's not horribly relevant. The problem could also be triggered by someone mistakenly missing their payment window to the RIR. From randy@psg.com Mon Nov 14 19:08:22 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCC51F0CA6 for ; Mon, 14 Nov 2011 19:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkDgoCZcXbsu for ; Mon, 14 Nov 2011 19:08:21 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C55EF1F0C98 for ; Mon, 14 Nov 2011 19:08:21 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RQ9Nk-0003SR-DK; Tue, 15 Nov 2011 03:08:20 +0000 Date: Tue, 15 Nov 2011 11:08:19 +0800 Message-ID: From: Randy Bush To: "Murphy, Sandra" In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F603227E@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6025FEE@Hermes.columbia.ads.sparta.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 03:08:22 -0000 > One clarification. I included Eric below as he was one of those who > took offense at the conclusion Steve drew from Brian's remark about > colleagues. Unfortunately, "you" is both singular and plural, so the > text as written implies that Eric colluded in the remark about > "colleagues". I should definitely have said "If Brian meant". uh, when is recess and can we play skitter ball? From danny@tcb.net Mon Nov 14 19:58:09 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCE21F0CBB for ; Mon, 14 Nov 2011 19:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyQoIJM-03q4 for ; Mon, 14 Nov 2011 19:58:09 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id EC38E1F0CC0 for ; Mon, 14 Nov 2011 19:58:08 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id B0CA6268063; Mon, 14 Nov 2011 20:58:08 -0700 (MST) Received: from dhcp-1267.meeting.ietf.org (dhcp-1267.meeting.ietf.org [130.129.18.103]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 14 Nov 2011 20:58:08 -0700 (MST) (envelope-from danny@tcb.net) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Mon, 14 Nov 2011 22:57:50 -0500 Content-Transfer-Encoding: 7bit Message-Id: <73084175-C365-4134-8C35-9892115504E8@tcb.net> References: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> <20111114234754.33CA96550DD@minas-ithil.hactrn.net> <87819BD9-1829-438C-A479-A315819943D0@tcb.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] Origin Ops, TALs and Local TAs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 03:58:09 -0000 On Nov 14, 2011, at 10:07 PM, Christopher Morrow wrote: > On top of that if the resource is then re-certified (to the same or > different end entity) how do the intermediate parties know which is > the 'right' thing to do? Agreed.. It's critical to highlight that LTA doesn't fix anything here unless this is accommodated by all parties in the transaction path. Furthermore, because CAs can be compromised (as we've seen with many CAs whose @day_job IS security), and today anyone in your TAL list can assert authority for any resources (as many are currently doing currently), without the ability to filter this or scope it in some manner it could be really problematic. -danny From eosterweil@verisign.com Mon Nov 14 20:29:07 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA1B11E80A4 for ; Mon, 14 Nov 2011 20:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rA7cOCQxoO82 for ; Mon, 14 Nov 2011 20:29:07 -0800 (PST) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 87A1311E8175 for ; Mon, 14 Nov 2011 20:29:06 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKTsHqib69UnG9NRxlKl7ank+5jDeHYrrS@postini.com; Mon, 14 Nov 2011 20:29:06 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id pAF4Subv027577; Mon, 14 Nov 2011 23:28:56 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.69]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Nov 2011 23:28:55 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Tue, 15 Nov 2011 12:28:48 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> <3F1388E3-A694-42C9-AE2F-F12BF15DC86F@verisign.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 15 Nov 2011 04:28:56.0175 (UTC) FILETIME=[167A27F0:01CCA34F] Cc: "sidr@ietf.org list" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 04:29:07 -0000 On Nov 15, 2011, at 10:53 AM, Stephen Kent wrote: > Eric, >=20 > i think we are making progress. thanks for the feedback. >=20 >> ... >>=20 >> I really think we should address these issues in a single document. = It seems like splitting this off into a separate/as yet unwritten = document is likely to cause some problems. In particular, since that = document does not yet exist, and it may not be written and adopted for = some time, this draft will not be complete on its own. I'm worried that = it is hard to judge this document's readiness w/o these timeline issues = worked out or even broached (as they may demand changes to this = process). Besides, isn't the corpus of drafts rather extensive already = (w/o adding another)? :) >=20 > My motivation for a separate timetable (vs. timeline) doc is that = there seems to be some agreement that this doc should be a product of = the operator community. The alg transition doc is an IETF architectural = statement, the product of this WG. I can't see combining the two. Did I = misunderstand your concern here? Yes, there is a misunderstanding. This draft is documenting a formal = process. The snipped text included the statement: "It is also RECOMMENDED that the timeline document describe procedures = to track the progress of the transition and to amend the timeline, e.g., = if problems arise in implementing later phases of the transition." I really think that the procedures associated with this process need to = be documented here in the same place (i.e. one draft). >=20 >> ... >>=20 >> OK, I see. But, aren't there second-order effects of this that we = have to worry about? For example, if I am an ISP whose CA performs the = rollover properly, but my upstream's CA does not, then their CA's = failure to keep up will cause my ISP to no longer be able to participate = in BGPsec, right (because I'm no longer part of a contiguous BGPsec = island)? I realize this is a bit different than my original example, = but upon thinking about the motivation for my comment, my point was more = general. It was that transitioning a CA to this state can have very = undesirable effects. >=20 > What you say that you performed the rollover but the CA above you = didn't can you be more specific, re the phase number? After Phase 4, when some CAs may be orphaned. To quote the draft: "a[n] RP that does not follow this process will lose the ability to validate signed products issued under the new algorithm suite." >=20 >> kewl, thnx. One minor nit: can we rephrase one part for clarity. = Instead of "If a problem arises that makes this infeasible for a = substantial number of CAs," can we just specify a little bit about how = this is determined. Maybe something like, "If deems a problem to have = arisen that is significant enough to make this infeasible for a = significant enough number of CAs..." >=20 > Good suggestion. I had already changed the text to the following form. >=20 > If it is determined that a substantial number of CAs are unable >=20 > Since we don't have a good placeholder for the bracketed entity I = think it's easier to make the statement without say who makes the = determination. Kewl, thnx. As a broad question, do we think there will be a point when = we can name an operational body who will manage this process, and if so, = will we put this in a draft? >> ... >>=20 >> I think this is a very strange comment (and I note that you said it = earlier in this email too). "Use of the RPKI... is optional." Is the = goal of this system to protect the global routing infrastructure or not? >=20 > The goal of this work does not imply that we can force all ISPs to = adopt it. We hope that the RPKI will be very widely deployed and used, = but we acknowledge that it may not me universal. So, both initially and = perhaps forever, the world will consist of resources that are protected = by certs and ROAs, and ones that are not. >=20 >> Unless we are talking about making this an experimental expedition, = and are prepared to create a globally applicable system later? >=20 > that's not a sentence :-). Yeah it is, I can speak to this at the mic... ;) In the meantime: Are we talking about making this an experimental expedition? Follow on = question, are we prepared to create a globally applicable system later? >> If the goal is to secure the global routing system (note I am not = saying universal deployment in the foreseeable future, just global = applicability), then this is an operational non-starter. >=20 > I'm glad that we agree that universal deployment is not a likely near = term event. We also agree that the RPKI is globally applicable . No, I was questioning the global applicability. I am worried that the = way BGPsec and RPKI are currently married is not globally applicable, in = the current form.=20 > Neitehr of these observations conflict with the fact that its use by = an network operator is optional. True, but my point is still that there is a rather striking misalignment = between the design and operational invariants. I'm trying to see your = points and how this might not be true, but claiming that we've agreed = when it's plain that we have not is... not as productive as it could = be... :) >=20 >> I do not believe it is appropriate for us to try and re-legislate = operational axioms in these drafts. What we could be doing is grossly = misaligning this standards work with operational invariants. >=20 > I no longer know what you are referring to. I have said that we cannot = mandate adherence to this process. We can offer it as a preferred = approach and hope that it is followed. We have incorporated a number of = phases so that there is an opportunity to verify the status of the = transition, and to allow the timeline to be pushed back if necessary. if = what you are saying is that we ought not specify any process that calls = for CAs and RPs to try to execute a transition in a coordinated fashion, = over a long time interval, then we have an impasse. The disagreement is = based on perceptions, on both of our parts, not facts. I think the distinct lack of another instance of this kind of = operational requirement in modern Internet-scale systems should be cause = for pause here. As I said back at the beginning of this thread: "Sorry, but I think freedom from global coordination is more than an = inconvenient, or unpalatable, concept. It is something that (afaict) = has been an inherent requirement in those Internet-scale systems that = have survived to date. I don't think there is any precedent of an = operational system of this scale that requires this level of global = coordination of its configuration, is there? What Internet-scale system = of a scale remotely as large as BGP has this kind of global coordination = model? What is the evidence that such an approach will work here?" >>=20 >>=20 >> > To avoid more flame wars, I will duck your question about my views = on DNSSEC and accommodation of different algorithm suites :-). >> Shall I take that as a retraction of your comment? ;) >=20 > no. Then I would really like to understand. As DNSSEC (though not perfect, = in any way) is a system that has reached deployment trials and has a = growing body of operational practices, what were the "less rigorous" = criteria that were "not great?" Maybe we'll all agree, or maybe we'll = all learn... Eric= From jakob.heitz@ericsson.com Mon Nov 14 20:54:06 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7B11F0C5E for ; Mon, 14 Nov 2011 20:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHq4nwmred18 for ; Mon, 14 Nov 2011 20:54:05 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 775E51F0C4F for ; Mon, 14 Nov 2011 20:54:04 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAF4s2k9028088; Mon, 14 Nov 2011 22:54:03 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 14 Nov 2011 23:53:58 -0500 From: Jakob Heitz To: "George, Wes" , Randy Bush Date: Mon, 14 Nov 2011 23:51:51 -0500 Thread-Topic: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs) Thread-Index: Acyi4ERm4I04uc2cSeaDnVDPQLnq4gAVRYNQAACGhYAAApkZwAAAhpQA Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Sriram, Kotikalapudi" , sidr wg list Subject: Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 04:54:06 -0000 > From: George, Wes [mailto:wesley.george@twcable.com] > Sent: Monday, November 14, 2011 7:04 PM > To: Jakob Heitz; Randy Bush > Cc: Sriram, Kotikalapudi; sidr wg list > Subject: RE: [sidr] Burstiness of BGP updates (was: WGLC: draft- > ietf-sidr-bgpsec-reqs) >=20 > > From: Jakob Heitz [mailto:jakob.heitz@ericsson.com] > > Sent: Monday, November 14, 2011 8:47 PM > > To: George, Wes; Randy Bush > > Cc: Sriram, Kotikalapudi; sidr wg list > > Subject: RE: [sidr] Burstiness of BGP updates (was: WGLC: draft- > ietf- > > sidr-bgpsec-reqs) > > > > I can not believe that it will be 2X. >=20 > [WEG] the objective amount of impact is probably not the important > bit here. >=20 > > > > First case: A beacon will very rarely cause a different bestpath. > [WEG] True. However... your comment was not specific to beacons. > Also when it does, it makes the load problem you're trying to solve > worse. > > > > Second case: There is actually a changed route being updated. > > You will receive both a regular update and a signature. > > Only one of those will casue a new bestpath in the great majority > of > > cases. > > > > Basically, in the large majority of cases, a signature does not > change > > the bestpath. > > > [WEG] Not true. Bestpath in BGPSec land is chosen based on policy > informed by the difference between valid, invalid and unknown. Even > if the absence or presence of the signature only toggles the route > between valid and unknown, given that those have a defined policy > action (eg raise or lower local pref, etc), the only way to ensure > that receiving a signature later than the initial route update does > not trigger a change of best path (let alone a recompute that > doesn't trigger a change, which probably has nearly the same impact) > is to set ones policy such that unknown and valid are the same > preference. While that may be reasonable in early incremental > deployment, eventually I don't think that's a safe assumption, and > really eventually is when we have a scaling problem, not in early > deployment. Great, so you don't disagree that beacons mostly cause no change. That should cover the bulk of BGPSEC updates. That brings us a long way down from 2X. Now, for a regular update that changes the bestpath, the signature will likely come later (in my proposal). If it replaces an existing valid path, the bestpath will not change until the signature arrives. If it replaces no path, then the regular update will produce a bestpath change, but the signature will not. In the unlikely event that the signature arrives first, the bestpath may change twice. >=20 > Wes George -- Jakob Heitz. From christopher.morrow@gmail.com Mon Nov 14 21:09:05 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0422D1F0D5C for ; Mon, 14 Nov 2011 21:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.553 X-Spam-Level: X-Spam-Status: No, score=-103.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zcz9kncGzMgR for ; Mon, 14 Nov 2011 21:09:03 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBD61F0C4F for ; Mon, 14 Nov 2011 21:09:03 -0800 (PST) Received: by iaeo4 with SMTP id o4so10356397iae.31 for ; Mon, 14 Nov 2011 21:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=N06KUXcaw8eX8XgGqXwT1B7UsY4xYduI7UiAkJdJVqc=; b=AptS4Pi9eHNd0uWsnFWu1N8OZ7ZVVxqxm+OB6w+W9vn/mjAE0ubLE739hW81rmTm8A CH42oZecNxM+MF9+YbO06sN+eQny0i3dK8w0wAMf1oZnFhiO3QRDHcdXSqgvEd+tRKz8 HjN0hKR78KX7/bz0lwSCBcry8qvTU5hCRI+eo= MIME-Version: 1.0 Received: by 10.231.5.81 with SMTP id 17mr6005190ibu.31.1321333743171; Mon, 14 Nov 2011 21:09:03 -0800 (PST) Received: by 10.231.202.142 with HTTP; Mon, 14 Nov 2011 21:09:03 -0800 (PST) Date: Tue, 15 Nov 2011 00:09:03 -0500 Message-ID: From: Christopher Morrow To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] note to attendees in the meeting... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 05:09:05 -0000 in the case you missed the note at the beginning, a nice gentleman from Orange is going to videotape the entire slide-sets being presented. Be aware of this when you walk to the mic/etc. (If you have a problem with it, speak up first and he'll be nice) thanks! -chris From brian.peter.dickson@gmail.com Mon Nov 14 21:15:35 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BC91F0DB0 for ; Mon, 14 Nov 2011 21:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[AWL=-2.557, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bylVJa9UFmxr for ; Mon, 14 Nov 2011 21:15:35 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D84E81F0D12 for ; Mon, 14 Nov 2011 21:15:34 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so678219bkb.31 for ; Mon, 14 Nov 2011 21:15:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hfySpB8sZzq2dfBU4swXY6fvqvCzEwTGUFLIlKFKy24=; b=RDWzHXRrSk3cHRNtT7/y9j5rAasEiguRoKctwnTCp0wXoCzZ3JVcrQEv24U2R9RzD+ uBeI/QDgKEWSuL1rctN2HThAMsEJpZ1/MXCsWqf4qYdDlwFlPpILmikJ4s9sbitjLQYu SuyO92SjTM79AQ10h0G8qlvaYgKIMNwWLj08I= MIME-Version: 1.0 Received: by 10.205.138.17 with SMTP id iq17mr14659267bkc.118.1321334133982; Mon, 14 Nov 2011 21:15:33 -0800 (PST) Received: by 10.223.54.15 with HTTP; Mon, 14 Nov 2011 21:15:33 -0800 (PST) In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> Date: Tue, 15 Nov 2011 00:15:33 -0500 Message-ID: From: Brian Dickson To: Jakob Heitz Content-Type: text/plain; charset=ISO-8859-1 Cc: "Sriram, Kotikalapudi" , sidr wg list Subject: Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 05:15:35 -0000 Sorry to jump in here, but I think that there is a drifting into conjecture... It would be best to stay within the realm of facts. > Great, so you don't disagree that beacons mostly cause no change. > That should cover the bulk of BGPSEC updates. > > That brings us a long way down from 2X. There is no empirical basis for 2X, either in the general case or the specific case. If I understand the "beacon" concept correctly, this is the re-announcement from the origin, based on the expiry time? Is this correct? Then the impact to the listener will be: The sum of (per-prefix frequency x number of in-RIBs that prefix is heard over) [i=1..N, N = number of prefixes]. If someone has a router with 10 copies of the full routing table, and the median rate is 1/day, then this will be approximately 10 x (routing table size) per day. The routing table in the DFZ is about what, 350-400k? That would be roughly 4M/day, or 50/sec. Even modest border routers, for multi-homed networks (two upstreams and significant local peering), that could easily be 1M+/day or 12+/sec. On top of everything else generated by churn, which in the case of a leaf router is 2-3/sec. The basic principal is, unlike churn, where the peak amplitude is an issue, this is pervasive, affecting every received prefix over every link on which it is received, even when routing is stable. Brian From christopher.morrow@gmail.com Mon Nov 14 21:22:29 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE02811E81CB for ; Mon, 14 Nov 2011 21:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.545 X-Spam-Level: X-Spam-Status: No, score=-103.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WkYlw5nIvkp for ; Mon, 14 Nov 2011 21:22:28 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BCC0E11E8073 for ; Mon, 14 Nov 2011 21:22:28 -0800 (PST) Received: by iaeo4 with SMTP id o4so10370262iae.31 for ; Mon, 14 Nov 2011 21:22:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yKa8h4JhAFMFKGbgX5/uxlfggI65en4h2kHEyOhY0no=; b=TaX3Hj9bW1EumsrpLrjhda6MX4kTkoQkBTPnXZkh5gtFxrTEOlSiK0gS9+gobJQqKu LL9VKfNALdaW8W67BbTu8CVM/20/X1rcHI9tyas0rWceyoGs9JrbxtC4pug4hEsHJpBf nhJV7U20bGVEjZmdAML27Z8lLmyp8BUgm/bbU= MIME-Version: 1.0 Received: by 10.231.5.81 with SMTP id 17mr6012319ibu.31.1321334548331; Mon, 14 Nov 2011 21:22:28 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Mon, 14 Nov 2011 21:22:28 -0800 (PST) In-Reply-To: <73084175-C365-4134-8C35-9892115504E8@tcb.net> References: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> <20111114234754.33CA96550DD@minas-ithil.hactrn.net> <87819BD9-1829-438C-A479-A315819943D0@tcb.net> <73084175-C365-4134-8C35-9892115504E8@tcb.net> Date: Tue, 15 Nov 2011 00:22:28 -0500 X-Google-Sender-Auth: kRiQCTxF4FRDpCkPvKsXHo3Dg0w Message-ID: From: Christopher Morrow To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] Origin Ops, TALs and Local TAs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 05:22:29 -0000 On Mon, Nov 14, 2011 at 10:57 PM, Danny McPherson wrote: > > On Nov 14, 2011, at 10:07 PM, Christopher Morrow wrote: > >> On top of that if the resource is then re-certified (to the same or >> different end entity) how do the intermediate parties know which is >> the 'right' thing to do? > > Agreed.. =A0It's critical to highlight that LTA doesn't fix anything here > unless this is accommodated by all parties in the transaction path. > in one sense, LTA is meant to certify resources local to the ASN (or set of ASNs which use the LTA, of course). It could be to cerify 'blackhole' routes, or RFC1918-like space. in another it's been bent for the 'stop the black-helicopters' problem (or the less controversal: 'Joe forgot to pay ARIN' case). So far your comments, I think, are about this use-case. > Furthermore, because CAs can be compromised (as we've seen with > many CAs whose @day_job IS security), and today anyone in your TAL also, we ought to be clear that the 'CA' is really one 'CA' at the root, we hope. which is both good and bad... > list can assert authority for any resources (as many are currently doing > currently), without the ability to filter this or scope it in some manner= it > could be really problematic. agreed, can we only have one root CA please? :) Having more than 1 is just asinine. (imho) -chris From michael.meulle@orange.com Mon Nov 14 21:32:03 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AD721F8E66 for ; Mon, 14 Nov 2011 21:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqtJeiIYncTs for ; Mon, 14 Nov 2011 21:32:01 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0A09221F8E39 for ; Mon, 14 Nov 2011 21:32:01 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 38AD48B8005; Tue, 15 Nov 2011 06:33:04 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 2F85C8B8001; Tue, 15 Nov 2011 06:33:04 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 06:32:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Nov 2011 06:31:57 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sidr] note to attendees in the meeting... Thread-Index: AcyjVLRTaF1XKFi+SIyh/7NdlqQS4QAAvmLw References: From: To: , X-OriginalArrivalTime: 15 Nov 2011 05:32:00.0346 (UTC) FILETIME=[E604D3A0:01CCA357] Subject: Re: [sidr] note to attendees in the meeting... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 05:32:03 -0000 Thank you for clarification, indeed i'm keeping video trace of the = meeting for myself (in addition to the great amount of material already = available, yes) Thank you and I can stop the process of course if anybody complains, Mickael -----Message d'origine----- De=A0: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] De la part = de Christopher Morrow Envoy=E9=A0: mardi 15 novembre 2011 06:09 =C0=A0: sidr@ietf.org Objet=A0: [sidr] note to attendees in the meeting... in the case you missed the note at the beginning, a nice gentleman from Orange is going to videotape the entire slide-sets being presented. Be aware of this when you walk to the mic/etc. (If you have a problem with it, speak up first and he'll be nice) thanks! -chris _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From wesley.george@twcable.com Mon Nov 14 21:46:07 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A6811E817A for ; Mon, 14 Nov 2011 21:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.783 X-Spam-Level: X-Spam-Status: No, score=-0.783 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHBCk9q7yQbT for ; Mon, 14 Nov 2011 21:45:58 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 65B5E11E809C for ; Mon, 14 Nov 2011 21:45:51 -0800 (PST) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,512,1315195200"; d="scan'208";a="297417091" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 15 Nov 2011 00:41:21 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Tue, 15 Nov 2011 00:45:49 -0500 From: "George, Wes" To: Brian Dickson , Jakob Heitz Date: Tue, 15 Nov 2011 00:46:13 -0500 Thread-Topic: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs) Thread-Index: AcyjVZuiqzXhBLugQpm8ls4lPTtADQAA0NRA Message-ID: References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Sriram, Kotikalapudi" , sidr wg list Subject: Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 05:46:12 -0000 > From: Brian Dickson [mailto:brian.peter.dickson@gmail.com] > Sent: Tuesday, November 15, 2011 12:16 AM > Sorry to jump in here, but I think that there is a drifting into > conjecture... > > It would be best to stay within the realm of facts. [WEG] To clarify, the issue got conflated between the impact of simple beac= on updates and the case where an actual route update comes in, but the sign= ature is processed after the update is processed, potentially triggering a = route recalc. Route recalc does mean 2x the processing, WHEN it happens, but it will not = happen in all cases. My apologies for being unclear. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From christopher.morrow@gmail.com Mon Nov 14 22:33:39 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E9F1F0DC1 for ; Mon, 14 Nov 2011 22:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.558 X-Spam-Level: X-Spam-Status: No, score=-103.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWv15qEB6x6I for ; Mon, 14 Nov 2011 22:33:38 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 828B51F0DC7 for ; Mon, 14 Nov 2011 22:33:35 -0800 (PST) Received: by iaeo4 with SMTP id o4so10444120iae.31 for ; Mon, 14 Nov 2011 22:33:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Mpyl4M+DXfE02Z+8jiTTUeBPUGCNl0rmp4NL03Om/uw=; b=NDT2LUq15OTUYoHLHSbXtQMIrHXBXS2yi1hccb1BHWw086wP9sZiR50mUZF65s1NaS Jmpuc1/a/J3TY+QS0m9Vaw8Uju2kRHryw16GrJb+7W29uNSlZY5JWpqEbFrFcmXHWAOF ZaLt3oTNyMMcO8+5/RNTGu8Vgmc4Y6bpUhFlg= MIME-Version: 1.0 Received: by 10.231.68.20 with SMTP id t20mr6062181ibi.18.1321338815052; Mon, 14 Nov 2011 22:33:35 -0800 (PST) Received: by 10.231.202.142 with HTTP; Mon, 14 Nov 2011 22:33:35 -0800 (PST) Date: Tue, 15 Nov 2011 01:33:35 -0500 Message-ID: From: Christopher Morrow To: sidr@ietf.org, Elisa Jasinska Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] transparent route-servers question(s) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 06:33:39 -0000 Elisa, In the meeting you noted that: "Some route servers don't have an ASN, some use a private-asn" Do you have some examples of these? Some quick doc searching (not by me) noted that all docs point to using a public-ASN... Err, so confusion reigns, could you help here? -chris From randy@psg.com Mon Nov 14 22:36:54 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0DD1F0DCE for ; Mon, 14 Nov 2011 22:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uH7vQW1K0s2R for ; Mon, 14 Nov 2011 22:36:53 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id B96941F0DCD for ; Mon, 14 Nov 2011 22:36:53 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RQCdY-0003yl-EX; Tue, 15 Nov 2011 06:36:52 +0000 Date: Tue, 15 Nov 2011 14:36:51 +0800 Message-ID: From: Randy Bush To: Elisa Jasinska In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] transparent route-servers question(s) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 06:36:54 -0000 > "Some route servers don't have an ASN, some use a private-asn" i have had a small visit by a clue bat. if two RSs use AS 65666, where is the cert for that AS? oops! randy From Sandra.Murphy@cobham.com Tue Nov 15 13:25:02 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7291F0C5D for ; Tue, 15 Nov 2011 13:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdQV7bTBKZ9x for ; Tue, 15 Nov 2011 13:25:02 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 40AA21F0C41 for ; Tue, 15 Nov 2011 13:25:01 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id pAFLOwrc005810 for ; Tue, 15 Nov 2011 15:24:58 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id pAFLOwIX015779 for ; Tue, 15 Nov 2011 15:24:58 -0600 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0339.001; Tue, 15 Nov 2011 16:24:58 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: meeting run over and shortened presentations Thread-Index: Acyj3KGfLib+8UsMRziFJFNdCFqXhA== Date: Tue, 15 Nov 2011 21:24:57 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6032B3F@Hermes.columbia.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.24] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] meeting run over and shortened presentations X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 21:25:03 -0000 The discussions in the meeting were energetic enough that we ran long - unt= il the next working group kicked us out, actually.=0A= =0A= The unfortunate result is that Bert, Matthias, and Sriram gave shortened an= d rushed presentations of their part of the agenda to a reduced audience.= =0A= =0A= In the next meeting, perhaps they will be first on the agenda.=0A= =0A= In the meantime - I invite the wg to look at the slides on the meeting mate= rials site. Post comments to the list or, if you are present in Taipei, co= rner Bert, Matthias or Sriram and ask questions.=0A= =0A= --Sandy=0A= From pmohapat@cisco.com Tue Nov 15 15:39:36 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FF611E8127 for ; Tue, 15 Nov 2011 15:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4X5BLeIvQn-W for ; Tue, 15 Nov 2011 15:39:35 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCD011E8119 for ; Tue, 15 Nov 2011 15:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pmohapat@cisco.com; l=1505; q=dns/txt; s=iport; t=1321400375; x=1322609975; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8UI7JBEvv1ZuSzOr0pH6s7zwOpVpAqYJYGIBtlnnHuE=; b=hUCEtQEHJs6s97a3qi/VNZOQovkhV7YrDmhH6Jp1X8KLt8aD93rNDOel stIZMVXOn4DW/5UkuFNv9v+gJUwBho5hWO7j/vabTXgvjwpjSaysSqrHs 7VSNjePzvxz9Y40LcHJeX9QU/7jkgRyCwXiDUqPbBG/7+kDun4WCHP/Xy s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJz3wk6rRDoH/2dsb2JhbABDqXGBBYFyAQEBAwESASUCPwULC0ZXBicOh2CaOwGeTIkuYwSIE4wfhTuMYA X-IronPort-AV: E=Sophos;i="4.69,517,1315180800"; d="scan'208";a="14438867" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 15 Nov 2011 23:39:35 +0000 Received: from [10.155.34.168] ([10.155.34.168]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAFNdZiW032096; Tue, 15 Nov 2011 23:39:35 GMT Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Pradosh Mohapatra In-Reply-To: <74F0D6F4-EA7B-4B2E-B195-D34448CD4CDF@tcb.net> Date: Tue, 15 Nov 2011 15:39:35 -0800 Content-Transfer-Encoding: 7bit Message-Id: <0A1020B9-07CB-4558-97C2-AE49AC9E8ED4@cisco.com> References: <74F0D6F4-EA7B-4B2E-B195-D34448CD4CDF@tcb.net> To: Danny McPherson X-Mailer: Apple Mail (2.1075.2) Cc: sidr wg list Subject: Re: [sidr] Comment on draft-ietf-sidr-origin-validation-signaling-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 23:39:36 -0000 Hi Danny, Thanks for the comments. > In general, I don't like the idea of using an extcomm community to > convey > a prefixes validation state, I think we should deal with this > problem natively > (e.g., as BGPSEC inter-domain) if we're going to address the > problem, in > particular if we're not going to address the AS Confederations > problem. Can you describe specific concerns you have with using extended community? It does work with confederations. > Furthermore, I don't like the deployment considerations, in > particular because > of "privilege escalation attacks" which could easily occur through > misconfiguration > across multiple attribute mapping functions, or simply because the > extcomm was > received from an BGP peer that isn't "upgraded to support the > extensions > defined in this document": > > "In deployment scenarios where not all the speakers in an autonomous > system are upgraded to support the extensions defined in this > document, it is necessary to define policies that match on the > origin > validation extended community and set another BGP attribute > [I-D.ietf-sidr-pfx-validate] that influences the best path selection > the same way as what would have been enabled by an implementation of > this extension." Do you have alternatives in mind for incremental deployment case? > Finally, this should certainly a normative reference in the pfx- > validate draft. Ack. - Pradosh From danny@tcb.net Tue Nov 15 16:56:37 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F147D11E80B2 for ; Tue, 15 Nov 2011 16:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nt7XSH8a9NIG for ; Tue, 15 Nov 2011 16:56:37 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id E877811E8082 for ; Tue, 15 Nov 2011 16:56:36 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 85A4A268063; Tue, 15 Nov 2011 17:56:36 -0700 (MST) Received: from [172.16.6.19] (122.147.35.3 [122.147.35.3]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 15 Nov 2011 17:56:36 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=122.147.35.3; client-port=53094; syn-fingerprint=65535:44:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <0A1020B9-07CB-4558-97C2-AE49AC9E8ED4@cisco.com> Date: Tue, 15 Nov 2011 19:56:29 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <74F0D6F4-EA7B-4B2E-B195-D34448CD4CDF@tcb.net> <0A1020B9-07CB-4558-97C2-AE49AC9E8ED4@cisco.com> To: Pradosh Mohapatra X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] Comment on draft-ietf-sidr-origin-validation-signaling-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 00:56:38 -0000 On Nov 15, 2011, at 6:39 PM, Pradosh Mohapatra wrote: > Can you describe specific concerns you have with using extended community? > It does work with confederations. Confederation in this context was referring to the _current inability of BGPSEC to natively accommodate AS confederations, or IBGP in general, for that matter, where Member-ASes commonly apply 'policy' at Member-ASBRs and no implicit transitive trust relationship would exist. While I don't want to overly conflate this function with that issue, it does intersect in that Opaque Extended Communities already assume a transitive trust relationship and in a world where the value of an Opaque Extended Community would be used to convey the validation state of a prefix an IBGP speaker has no way to validate the semantic integrity of the string. Its essentially what I have today, and into the future secure routing should enable me to verify this. > Do you have alternatives in mind for incremental deployment case? I'm not sure what you mean by "incremental deployment" here, are you referring to the case where it gets enabled and deployed but no IBGP speaker applies policy based on the validation state until all IBGP speakers support prefix origin validation capability as defined in the document? I suspect this is what S3.1 is implicitly conveying. I'm not convinced incremental deployment of the validation state processing capability within IBGP should be supported. The current Deployment Considerations section makes me uneasy in that it's essentially saying "if you don't support this Opaque value and decision algorithm modification as prescribed in S.3 then you should develop static policy maps that influences the best path selection *the same way* as what would have been enabled by an implementation of this extension." -- i.e., that may not even be feasible in some operating environments and the complexity it presents is likely conducive to misconfiguration that introduce forwarding loops in the network. Does that make sense? -danny From russw@riw.us Tue Nov 15 17:31:19 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC87B11E8138 for ; Tue, 15 Nov 2011 17:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxR0gVWM00Na for ; Tue, 15 Nov 2011 17:31:19 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6A511E812C for ; Tue, 15 Nov 2011 17:31:19 -0800 (PST) Received: from [107.17.45.77] (port=65335) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RQULN-0007aH-5w for sidr@ietf.org; Tue, 15 Nov 2011 20:31:17 -0500 Message-ID: <4EC3125D.4000309@riw.us> Date: Tue, 15 Nov 2011 20:31:09 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: sidr@ietf.org References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 01:31:19 -0000 >>> I can not believe that it will be 2X. It will likely be worse. > Now, for a regular update that changes the bestpath, the signature > will likely come later (in my proposal). If it replaces an existing > valid path, the bestpath will not change until the signature arrives. > If it replaces no path, then the regular update will produce a bestpath > change, but the signature will not. So you are arguing that if you have two signed paths, and you receive a new unsigned path replacing one of the signed paths --in fact, replacing the signed path that is currently your bestpath-- you would keep using the old bestpath even though it has a lower security preference than the other existing signed path. How does a system that says, "replay attacks are okay, you may accept unsigned information over signed information, it's okay if timers are expired, it's okay if AS' in the middle of that path can be attacked through replays, etc.," really provide security? I'm seeing a lot of work for little to no net gain here. :-) Russ From jakob.heitz@ericsson.com Tue Nov 15 18:50:15 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC79C11E8164 for ; Tue, 15 Nov 2011 18:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.22 X-Spam-Level: X-Spam-Status: No, score=-6.22 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZHfhfhgKg78 for ; Tue, 15 Nov 2011 18:50:11 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA2111E8151 for ; Tue, 15 Nov 2011 18:50:11 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAG2o8MG021398; Tue, 15 Nov 2011 20:50:10 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 15 Nov 2011 21:50:07 -0500 From: Jakob Heitz To: Russ White , "sidr@ietf.org" Date: Tue, 15 Nov 2011 21:50:04 -0500 Thread-Topic: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs) Thread-Index: Acyj/3kh5VnJ46rLRJu60THnXRpdZwACSK4Q Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> In-Reply-To: <4EC3125D.4000309@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 02:50:16 -0000 How to treat unsigned paths is a matter of policy. This is up to each provider to configure as he pleases. I would prefer a signed route over an unsigned one, but prefer an unsigned route over no route. For more security sensitive routes, you may prefer no route over an unsigned route. It's up to you. I am saying, do not delay the regular updates. Send the signatures in a separate connection. A performance sensitive implementation does both the signing and the checking in a low priority process anyway. That results in two updates, one with the regular update followed by a copy with the signature. I am saying to put that signature into a separate connection, so as not to delay the higher urgency regular updates. -- Jakob Heitz. > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf > Of Russ White > Sent: Tuesday, November 15, 2011 5:31 PM > To: sidr@ietf.org > Subject: Re: [sidr] Burstiness of BGP updates (was: WGLC: draft- > ietf-sidr-bgpsec-reqs) >=20 >=20 >=20 > >>> I can not believe that it will be 2X. >=20 > It will likely be worse. >=20 > > Now, for a regular update that changes the bestpath, the signature > > will likely come later (in my proposal). If it replaces an > existing > > valid path, the bestpath will not change until the signature > arrives. > > If it replaces no path, then the regular update will produce a > > bestpath change, but the signature will not. >=20 > So you are arguing that if you have two signed paths, and you > receive a new unsigned path replacing one of the signed paths --in > fact, replacing the signed path that is currently your bestpath-- > you would keep using the old bestpath even though it has a lower > security preference than the other existing signed path. >=20 > How does a system that says, "replay attacks are okay, you may > accept unsigned information over signed information, it's okay if > timers are expired, it's okay if AS' in the middle of that path can > be attacked through replays, etc.," really provide security? I'm > seeing a lot of work for little to no net gain here. >=20 > :-) >=20 > Russ > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From russw@riw.us Tue Nov 15 19:11:19 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C35211E80D4 for ; Tue, 15 Nov 2011 19:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJ0wf1kR-vGS for ; Tue, 15 Nov 2011 19:11:18 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id AF1E111E80B0 for ; Tue, 15 Nov 2011 19:11:17 -0800 (PST) Received: from [107.17.45.77] (port=49729) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RQVu1-0007Oq-3k; Tue, 15 Nov 2011 22:11:09 -0500 Message-ID: <4EC329C6.4090600@riw.us> Date: Tue, 15 Nov 2011 22:11:02 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Jakob Heitz References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: "sidr@ietf.org" Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 03:11:19 -0000 > How to treat unsigned paths is a matter of policy. Correct --but if you're going to, by default, not treat signed routes as primary over unsigned ones, what's the point of the signatures? > For more security sensitive routes, you may prefer no route > over an unsigned route. It's up to you. In who's opinion? Yours or the originators? Since this is all about making certain you're following the intent of the originator, I'd think the originator's opinion is the one that counts here, not yours. > I am saying to put that signature into a separate > connection, so as not to delay the higher urgency > regular updates. Sorry, but I don't see how this really helps... What if I'm really lazy, and just never process the signatures? What if I use a route for several minutes, then suddenly realize it's not a valid route? Is it okay to steal 500 people's usernames and passwords, and not 1000? Time is an important element in routing systems, both for convergence and security. :-) Russ From jakob.heitz@ericsson.com Tue Nov 15 19:29:53 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D21B11E80B1 for ; Tue, 15 Nov 2011 19:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.34 X-Spam-Level: X-Spam-Status: No, score=-6.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAHuK3AC36FI for ; Tue, 15 Nov 2011 19:29:53 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2391711E8095 for ; Tue, 15 Nov 2011 19:29:53 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAG3TlYv022932; Tue, 15 Nov 2011 21:29:52 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 15 Nov 2011 22:29:42 -0500 From: Jakob Heitz To: Russ White Date: Tue, 15 Nov 2011 22:29:40 -0500 Thread-Topic: [sidr] Burstiness of BGP updates Thread-Index: AcykDWyVP4DmM8cmR5+FuAQQ4oXUkwAAXpRw Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> In-Reply-To: <4EC329C6.4090600@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 03:29:53 -0000 > -----Original Message----- > From: Russ White [mailto:russw@riw.us] > Sent: Tuesday, November 15, 2011 7:11 PM >=20 > Sorry, but I don't see how this really helps... What if I'm really > lazy, and just never process the signatures? What if I use a route > for several minutes, then suddenly realize it's not a valid route? > Is it okay to steal 500 people's usernames and passwords, and not > 1000? Time is an important element in routing systems, both for > convergence and security. I don't understand how BGPSEC is going to prevent anyone stealing passwords. To me, all this talk of BGP validation preventing hacks is a load of fantasy. The only utility I can see is in protecting reachability. The only problem I can imagine with installing an unsigned route is that the destination becomes unreachable. If it was unreachable to begin with, no harm is done. -- Jakob Heitz. x25475. 510-566-2901 From russw@riw.us Tue Nov 15 19:32:23 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D641F0C45 for ; Tue, 15 Nov 2011 19:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDRcCNtB40cd for ; Tue, 15 Nov 2011 19:32:22 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id AC4B01F0C42 for ; Tue, 15 Nov 2011 19:32:22 -0800 (PST) Received: from [107.17.45.77] (port=49857) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RQWEW-0005PY-LR; Tue, 15 Nov 2011 22:32:20 -0500 Message-ID: <4EC32EBE.6030106@riw.us> Date: Tue, 15 Nov 2011 22:32:14 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Jakob Heitz References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: "sidr@ietf.org" Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 03:32:23 -0000 > The only utility I can see is in protecting reachability. > The only problem I can imagine with installing an unsigned > route is that the destination becomes unreachable. If it > was unreachable to begin with, no harm is done. When you're protecting reachability, what are you protecting? Whether or not someone can reach something. I assume that the "something" you're trying to protect reachability to would/must include things where you enter your password. Hence, I look at this entire problem a little differently than simply trying to enforce a small subset of policies, or as a theoretical exercise... If we can't prevent real world consequences with this work, then --why are we doing it? :-) Russ From jakob.heitz@ericsson.com Tue Nov 15 19:40:19 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323931F0CA9 for ; Tue, 15 Nov 2011 19:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.351 X-Spam-Level: X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73aQpZmk5av8 for ; Tue, 15 Nov 2011 19:40:18 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 93C1A1F0C9E for ; Tue, 15 Nov 2011 19:40:18 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAG3cZQK023302; Tue, 15 Nov 2011 21:38:36 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 15 Nov 2011 22:38:29 -0500 From: Jakob Heitz To: Russ White Date: Tue, 15 Nov 2011 22:38:27 -0500 Thread-Topic: [sidr] Burstiness of BGP updates Thread-Index: AcykEGqCWd1q2OPJTTWI4m04Lo8GEwAABryg Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> In-Reply-To: <4EC32EBE.6030106@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 03:40:19 -0000 > -----Original Message----- > From: Russ White [mailto:russw@riw.us] > Sent: Tuesday, November 15, 2011 7:32 PM > To: Jakob Heitz > Cc: sidr@ietf.org > Subject: Re: [sidr] Burstiness of BGP updates >=20 >=20 > > The only utility I can see is in protecting reachability. > > The only problem I can imagine with installing an unsigned route > is > > that the destination becomes unreachable. If it was unreachable to > > begin with, no harm is done. >=20 > When you're protecting reachability, what are you protecting? > Whether or not someone can reach something. I assume that the > "something" you're trying to protect reachability to would/must > include things where you enter your password. >=20 > Hence, I look at this entire problem a little differently than > simply trying to enforce a small subset of policies, or as a > theoretical exercise... If we can't prevent real world consequences > with this work, then --why are we doing it? We are doing it to protect reachability. We are not protecting your password in clear text on the internet. -- Jakob Heitz. x25475. 510-566-2901 From russw@riw.us Tue Nov 15 19:52:41 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E242D11E817B for ; Tue, 15 Nov 2011 19:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2yOKt5G71L5 for ; Tue, 15 Nov 2011 19:52:41 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 5825911E8172 for ; Tue, 15 Nov 2011 19:52:41 -0800 (PST) Received: from [107.17.45.77] (port=50371) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RQWY9-0000Wu-EL; Tue, 15 Nov 2011 22:52:37 -0500 Message-ID: <4EC3337D.3050704@riw.us> Date: Tue, 15 Nov 2011 22:52:29 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Jakob Heitz References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: "sidr@ietf.org" Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 03:52:42 -0000 > We are doing it to protect reachability. Again: >> When you're protecting reachability, what are you protecting? >> Whether or not someone can reach something. I assume that the >> "something" you're trying to protect reachability to would/must >> include things where you enter your password. >> >> Hence, I look at this entire problem a little differently than >> simply trying to enforce a small subset of policies, or as a >> theoretical exercise... If we can't prevent real world consequences >> with this work, then --why are we doing it? > We are not protecting your password in clear text on the internet. I would challenge you to find any statement of mine where I said this work is about "protecting your password in clear text on the internet." "The Internet" is not an abstract collection of "things." It is a set of reachable destinations. People go to those destinations to transact business. If people reach the wrong destination, they transact business with the wrong party. If a "security system," can't protect me from reaching the wrong destination on a system designed to get me to the right destination, then the security system is, generally speaking, useless. I do wish I didn't have to have users connected to the networks I design and work on --it would really make my life much simpler. But then again, no users, no network, right? I think we sometimes get so lost in the theory that we forget what networks are actually _for_. :-) Russ > > -- > Jakob Heitz. x25475. 510-566-2901 > From shankar.k.a@ericsson.com Tue Nov 15 20:06:41 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7421111E8194 for ; Tue, 15 Nov 2011 20:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbjyPAgU6IaW for ; Tue, 15 Nov 2011 20:06:37 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 02A3C11E811C for ; Tue, 15 Nov 2011 20:06:36 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-c5-4ec336cabe4c Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 27.FB.09514.AC633CE4; Wed, 16 Nov 2011 05:06:35 +0100 (CET) Received: from ESESSCMS0358.eemea.ericsson.se ([169.254.1.199]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 16 Nov 2011 05:06:34 +0100 From: Shankar K A To: Jakob Heitz , Russ White Date: Wed, 16 Nov 2011 05:06:29 +0100 Thread-Topic: [sidr] Burstiness of BGP updates Thread-Index: AcykEGqCWd1q2OPJTTWI4m04Lo8GEwAABrygAADal2A= Message-ID: References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sidr@ietf.org" Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 04:06:41 -0000 I would prefer signed updated over unsigned updates as Jakob suggested. But strictly speaking, IMO we should only accept signed updates, because it= 's the number of AS that we add in the update that we are protecting. By accepting unsigned update we may accept unprotected path information.=20 - Shankar K A -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Jak= ob Heitz Sent: Wednesday, November 16, 2011 9:08 AM To: Russ White Cc: sidr@ietf.org Subject: Re: [sidr] Burstiness of BGP updates > -----Original Message----- > From: Russ White [mailto:russw@riw.us] > Sent: Tuesday, November 15, 2011 7:32 PM > To: Jakob Heitz > Cc: sidr@ietf.org > Subject: Re: [sidr] Burstiness of BGP updates >=20 >=20 > > The only utility I can see is in protecting reachability. > > The only problem I can imagine with installing an unsigned route > is > > that the destination becomes unreachable. If it was unreachable to=20 > > begin with, no harm is done. >=20 > When you're protecting reachability, what are you protecting? > Whether or not someone can reach something. I assume that the=20 > "something" you're trying to protect reachability to would/must=20 > include things where you enter your password. >=20 > Hence, I look at this entire problem a little differently than simply=20 > trying to enforce a small subset of policies, or as a theoretical=20 > exercise... If we can't prevent real world consequences with this=20 > work, then --why are we doing it? We are doing it to protect reachability. We are not protecting your password in clear text on the internet. -- Jakob Heitz. x25475. 510-566-2901 _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From russw@riw.us Tue Nov 15 20:39:44 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47AF1F0C4B for ; Tue, 15 Nov 2011 20:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5e6jzz8k5OBV for ; Tue, 15 Nov 2011 20:39:44 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 270011F0C47 for ; Tue, 15 Nov 2011 20:39:44 -0800 (PST) Received: from [107.17.45.77] (port=49946) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RQXHh-0006cS-JA; Tue, 15 Nov 2011 23:39:41 -0500 Message-ID: <4EC33E88.9090505@riw.us> Date: Tue, 15 Nov 2011 23:39:36 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Shankar K A References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: "sidr@ietf.org" Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 04:39:44 -0000 > But strictly speaking, IMO we should only accept signed updates, because it's the number of AS that we add in the update that we are protecting. > By accepting unsigned update we may accept unprotected path information. Precisely my point. :-) Russ From christopher.morrow@gmail.com Tue Nov 15 20:39:54 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0706B1F0C74 for ; Tue, 15 Nov 2011 20:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.547 X-Spam-Level: X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iawdXQPcwF2 for ; Tue, 15 Nov 2011 20:39:53 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 84D0F1F0C54 for ; Tue, 15 Nov 2011 20:39:53 -0800 (PST) Received: by iaeo4 with SMTP id o4so72290iae.31 for ; Tue, 15 Nov 2011 20:39:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TrPQEp0W3E/LDHgdqI758kJyDHlsLDp7rRKjPapkhbs=; b=CHsgDGbDN7fGFT3tZtMeb2XfDbCgM1NeSvhHyEo5gzFzn3BYKmX4NMnn/Z5TTau/Gh yJchPNX5weHauITM1l4j+7gV9GNrp3PnLBcLZabBRoKY8kqqN8GasaXx9AeTpKKoIINZ p/CwsLBazZ+LKNCBCI0y/2q+i1bJ4UmucHmiE= MIME-Version: 1.0 Received: by 10.50.184.202 with SMTP id ew10mr30964905igc.48.1321418393209; Tue, 15 Nov 2011 20:39:53 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Tue, 15 Nov 2011 20:39:52 -0800 (PST) In-Reply-To: References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> Date: Tue, 15 Nov 2011 23:39:52 -0500 X-Google-Sender-Auth: TqrKo6jKznJoGqee_2TpxkJE9WA Message-ID: From: Christopher Morrow To: Shankar K A Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org" Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 04:39:54 -0000 On Tue, Nov 15, 2011 at 11:06 PM, Shankar K A wrote: > I would prefer signed updated over unsigned updates as Jakob suggested. > But strictly speaking, IMO we should only accept signed updates, because it's the number of AS that we add in the update that we are protecting. > By accepting unsigned update we may accept unprotected path information. > it really is, or was, the intent to permit operators of networks to decide this on their own. They MAY want to prefer unsigned/unknown/notfound/naked prefixes for certain things. It's really not up to us to say, is it? we can SUGGEST that they SHOULD prefer signed over unsigned, but in the end of the day it's on them. From shankar.k.a@ericsson.com Tue Nov 15 20:50:43 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A951F0CC1 for ; Tue, 15 Nov 2011 20:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRyekaTKzTVk for ; Tue, 15 Nov 2011 20:50:42 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9141F0CB1 for ; Tue, 15 Nov 2011 20:50:42 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-f6-4ec34121b721 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id ED.EF.09514.12143CE4; Wed, 16 Nov 2011 05:50:41 +0100 (CET) Received: from ESESSCMS0358.eemea.ericsson.se ([169.254.1.199]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 16 Nov 2011 05:50:41 +0100 From: Shankar K A To: Christopher Morrow Date: Wed, 16 Nov 2011 05:50:39 +0100 Thread-Topic: [sidr] Burstiness of BGP updates Thread-Index: AcykGcmiNrUtVPDFTp+42gEt07QD3wAALTrQ Message-ID: References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sidr@ietf.org" Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 04:50:43 -0000 I agree that we cannot force this. However, it should be ok if we can speci= fy these policies as best practices or recommendations. - Shankar K A -----Original Message----- From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com] On= Behalf Of Christopher Morrow Sent: Wednesday, November 16, 2011 10:10 AM To: Shankar K A Cc: Jakob Heitz; Russ White; sidr@ietf.org Subject: Re: [sidr] Burstiness of BGP updates On Tue, Nov 15, 2011 at 11:06 PM, Shankar K A wr= ote: > I would prefer signed updated over unsigned updates as Jakob suggested. > But strictly speaking, IMO we should only accept signed updates, because = it's the number of AS that we add in the update that we are protecting. > By accepting unsigned update we may accept unprotected path information. > it really is, or was, the intent to permit operators of networks to decide = this on their own. They MAY want to prefer unsigned/unknown/notfound/naked = prefixes for certain things. It's really not up to us to say, is it? we can= SUGGEST that they SHOULD prefer signed over unsigned, but in the end of th= e day it's on them. From jakob.heitz@ericsson.com Tue Nov 15 21:06:21 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481811F0CE0 for ; Tue, 15 Nov 2011 21:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.361 X-Spam-Level: X-Spam-Status: No, score=-6.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+zGEHfdC2BM for ; Tue, 15 Nov 2011 21:06:20 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id B81BA1F0C9B for ; Tue, 15 Nov 2011 21:06:20 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pAG56D2J029264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Nov 2011 23:06:13 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 16 Nov 2011 00:06:12 -0500 From: Jakob Heitz To: Russ White , Shankar K A Date: Wed, 16 Nov 2011 00:06:09 -0500 Thread-Topic: [sidr] Burstiness of BGP updates Thread-Index: AcykGcRG1uCuScnfShCD/Vas5tY7RAAAXqcg Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> In-Reply-To: <4EC33E88.9090505@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 05:06:21 -0000 > -----Original Message----- > From: Russ White [mailto:russw@riw.us] > Sent: Tuesday, November 15, 2011 8:40 PM > To: Shankar K A > Cc: Jakob Heitz; sidr@ietf.org > Subject: Re: [sidr] Burstiness of BGP updates >=20 >=20 > > But strictly speaking, IMO we should only accept signed updates, > because it's the number of AS that we add in the update that we are > protecting. > > By accepting unsigned update we may accept unprotected path > information. >=20 > Precisely my point. What is the value of that? Does this now allow me to send passwords in the clear on the internet? -- Jakob Heitz. From shankar.k.a@ericsson.com Tue Nov 15 21:09:32 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6BF21F90BA for ; Tue, 15 Nov 2011 21:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGWLLGw3TKcl for ; Tue, 15 Nov 2011 21:09:31 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3274A21F8DD9 for ; Tue, 15 Nov 2011 21:09:31 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-12-4ec3458a1af6 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E7.B1.09514.A8543CE4; Wed, 16 Nov 2011 06:09:30 +0100 (CET) Received: from ESESSCMS0358.eemea.ericsson.se ([169.254.1.199]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 16 Nov 2011 06:09:29 +0100 From: Shankar K A To: Jakob Heitz , Russ White Date: Wed, 16 Nov 2011 06:09:28 +0100 Thread-Topic: [sidr] Burstiness of BGP updates Thread-Index: AcykGcRG1uCuScnfShCD/Vas5tY7RAAAXqcgAACVgXA= Message-ID: References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sidr@ietf.org" Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 05:09:32 -0000 You cannot use BGP to enable you to send such messages. There could be mill= ion other ways to do what you are saying. After this, there is one less cha= nce. That's all. - Shankar K A=20 -----Original Message----- From: Jakob Heitz=20 Sent: Wednesday, November 16, 2011 10:36 AM To: Russ White; Shankar K A Cc: sidr@ietf.org Subject: RE: [sidr] Burstiness of BGP updates > -----Original Message----- > From: Russ White [mailto:russw@riw.us] > Sent: Tuesday, November 15, 2011 8:40 PM > To: Shankar K A > Cc: Jakob Heitz; sidr@ietf.org > Subject: Re: [sidr] Burstiness of BGP updates >=20 >=20 > > But strictly speaking, IMO we should only accept signed updates, > because it's the number of AS that we add in the update that we are=20 > protecting. > > By accepting unsigned update we may accept unprotected path > information. >=20 > Precisely my point. What is the value of that? Does this now allow me to send passwords in the clear on the internet? -- Jakob Heitz. From brian.peter.dickson@gmail.com Tue Nov 15 21:29:36 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AAA1F0CA7 for ; Tue, 15 Nov 2011 21:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.48 X-Spam-Level: X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6tP1knzyo3l for ; Tue, 15 Nov 2011 21:29:31 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 50E001F0C95 for ; Tue, 15 Nov 2011 21:29:31 -0800 (PST) Received: by faap16 with SMTP id p16so1293022faa.31 for ; Tue, 15 Nov 2011 21:29:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CAQIYDacn96xyKOrTka1bc+xmFzMw+ADYvt8+peiIqE=; b=NpuO/YSMt/tP5JdSTnARcsNH8pHZf9da9KEOnXwTONr0eO7nvOAazTLDosH3MU3Rzo 3Q7WVm2maFCLOtWpNf1w0ylw8Nu09RfAE8o31cXqygfx3oQnEBR5FpWWq6e752Mklyya oMc1gRx7k2fi9X/Gn1qAMYF8mN4ZGl+fXuKcc= MIME-Version: 1.0 Received: by 10.204.133.216 with SMTP id g24mr19639721bkt.82.1321421369345; Tue, 15 Nov 2011 21:29:29 -0800 (PST) Received: by 10.223.54.15 with HTTP; Tue, 15 Nov 2011 21:29:29 -0800 (PST) In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> Date: Wed, 16 Nov 2011 00:29:29 -0500 Message-ID: From: Brian Dickson To: Jakob Heitz Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org" Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 05:29:37 -0000 Understanding the "real" threats, and worked, real-world examples, is important. I cannot believe anyone in this WG would be ignorant of things like this: http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf Does this illustrate the importance of not only validating origins, but also only using signed prefixes if you are participating in BGPsec? And the importance of minimizing or eliminating the ability of someone currently off-axis, from becoming on-axis? Preferably eliminating exploitation of lack of proper trust boundaries WRT leakage (reannouncement permissions)? (It is difficult to change from off-axis to on-axis without "leaking" - the only time "leaking" isn't strictly required, is when already on-axis.) Jakob, please view the whole presentation above. It was more than 3 years ago... You should have heard of it by now. Brian From christopher.morrow@gmail.com Tue Nov 15 21:35:09 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFC31F0CD5 for ; Tue, 15 Nov 2011 21:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.548 X-Spam-Level: X-Spam-Status: No, score=-103.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiXg6ZDrL2BC for ; Tue, 15 Nov 2011 21:35:05 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C88AE1F0CE8 for ; Tue, 15 Nov 2011 21:35:03 -0800 (PST) Received: by ggnr5 with SMTP id r5so3598955ggn.31 for ; Tue, 15 Nov 2011 21:35:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/Mxo0FswjIVLR/c4BkBmgBY5+Km4nEMXeoVp+C9VSW0=; b=PFZQkCT9xFuRAr4RSHM8eOLifT7Yix+ymrTercqvVILKdlgfsvuAUFWsQilcDtm38F RbyX7/n0hgPCWNlENaq+dE47fJePxh1QC1DnMwa2UJFKuxtPDY0hes167O6e3/ll8CVF xi76wi3OapTCzhGCoh6WOY0BvULbQv/GBSnNE= MIME-Version: 1.0 Received: by 10.50.202.100 with SMTP id kh4mr31113773igc.41.1321421703179; Tue, 15 Nov 2011 21:35:03 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Tue, 15 Nov 2011 21:35:03 -0800 (PST) In-Reply-To: References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> Date: Wed, 16 Nov 2011 00:35:03 -0500 X-Google-Sender-Auth: hxucGAfaCu_cRSXOp2a_tl047p8 Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org" Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 05:35:10 -0000 On Wed, Nov 16, 2011 at 12:29 AM, Brian Dickson wrote: > Understanding the "real" threats, and worked, real-world examples, is important. > > I cannot believe anyone in this WG would be ignorant of things like this: > > http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf this is referred to several times in Stephen Kent's presentations actually, and in Randy's presentations to RIR/etc folk. > Does this illustrate the importance of not only validating origins, > but also only using signed prefixes if you are participating in > BGPsec? sure, but if your customer forgets to pay a bill, calls you up and (post proper 'this is the customer' authentication) says: "Hey, srsly, I forgot, checks in the mail to ARIN, can you accept our route pls?" you may be willing to do same, you may also be willing to do this in the case of internal services routes that you don't actually want externally visible. > And the importance of minimizing or eliminating the ability of someone > currently off-axis, from becoming on-axis? sure, see referenced slides from Kent. (and bgpsec as spec'd would squish pilosov/kapella) > Preferably eliminating exploitation of lack of proper trust boundaries > WRT leakage (reannouncement permissions)? re-announcement is 'harder' since it's not clear if NTT is supposed to be passing cogent aol's routes or not, is it? > (It is difficult to change from off-axis to on-axis without "leaking" > - the only time "leaking" isn't strictly required, is when already > on-axis.) > > Jakob, please view the whole presentation above. It was more than 3 > years ago... You should have heard of it by now. hopefully everyone's read it :) -chris From brian.peter.dickson@gmail.com Tue Nov 15 21:56:26 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E601F0D1C for ; Tue, 15 Nov 2011 21:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.483 X-Spam-Level: X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-xVak8BY1VR for ; Tue, 15 Nov 2011 21:56:25 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 66EB01F0D1A for ; Tue, 15 Nov 2011 21:56:25 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so147361bkb.31 for ; Tue, 15 Nov 2011 21:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UZpRVjdhcPEy5WhqsVOFNuFefuOggU02/SxstTMmRkQ=; b=SbXWlyMzJ34yNJ73K336fzrlEGYEmu05qHRDF8X2V4irkcHvzED7SUA4iLeDS6hAhL 0ti/84AUaOd11YqQ9rTeiBqmcziHWxdsKQH6hIH3tAEKgHTgxLLDlIslvh+qFddmQUWC cdoZUL9NdXgnJFVjdZLd/u76FU5JEl4ewpwFs= MIME-Version: 1.0 Received: by 10.205.138.17 with SMTP id iq17mr19563703bkc.118.1321422984394; Tue, 15 Nov 2011 21:56:24 -0800 (PST) Received: by 10.223.54.15 with HTTP; Tue, 15 Nov 2011 21:56:24 -0800 (PST) In-Reply-To: References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> Date: Wed, 16 Nov 2011 00:56:24 -0500 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org" Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 05:56:26 -0000 On Wed, Nov 16, 2011 at 12:35 AM, Christopher Morrow wrote: > On Wed, Nov 16, 2011 at 12:29 AM, Brian Dickson >> Does this illustrate the importance of not only validating origins, >> but also only using signed prefixes if you are participating in >> BGPsec? > > sure, but if your customer forgets to pay a bill, calls you up and > (post proper 'this is the customer' authentication) says: "Hey, srsly, > I forgot, checks in the mail to ARIN, can you accept our route pls?" I was using "only" in contrast to Jakob, who was suggesting having the same prefix and as-path, both signed and unsigned, be used, and in fact the unsigned used prior to validating the signatures. Basically, if you have BGPsec enabled with a given peer, you might get a combination of signed and unsigned from that peer - but for a given prefix, you MUST only get one or the other. Invalid-sig != unsigned. Accepting unsigned as a "fast" short-cut is insane, frankly. Signed prefix processing actually needs to "block" until the signature result is received. On a per-prefix basis, of course. This is why having your cache very close is important, as are any possible implementation optimizations or design considerations that improve signature processing/capacity/timeliness. > you may be willing to do same, you may also be willing to do this in > the case of internal services routes that you don't actually want > externally visible. Sure - and locally significant signatures/trust-anchors are very important for just such an occasion. (For any convenient value of "local", it should be noted. City, zip code, province, continent, building, whatever.) > > re-announcement is 'harder' since it's not clear if NTT is supposed to > be passing cogent aol's routes or not, is it? Agreed - I can't be specific on exactly when, but expect me to present something "real soon now" on a nuts-and-bolts level of how to do this. Maybe a month, maybe two. Brian From christopher.morrow@gmail.com Tue Nov 15 22:03:27 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BCD1F0D2F for ; Tue, 15 Nov 2011 22:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.55 X-Spam-Level: X-Spam-Status: No, score=-103.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTVpw-j6HZvS for ; Tue, 15 Nov 2011 22:03:26 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 117A11F0D29 for ; Tue, 15 Nov 2011 22:03:23 -0800 (PST) Received: by iaeo4 with SMTP id o4so160003iae.31 for ; Tue, 15 Nov 2011 22:03:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6MIyRbCrItY8vJSur5AQQtbatP3QxKcRTp6bqUinXzA=; b=b6vgCe8dt2XxMXQX3wccZZwdUkbcNvZWj2i2zTP6Kz6UotqY6sTdsHLR3j6Vog+ygF f+eFKCNXMWGMBwMDgYxXISrKu5JkavUN61s4oBUQdfYXU0msFax65DDCekr5pMARAqOY /ohn8CY/AvpjMB3TeuvIPUXQPkhZwB2okNYKU= MIME-Version: 1.0 Received: by 10.231.5.81 with SMTP id 17mr7154324ibu.31.1321423403661; Tue, 15 Nov 2011 22:03:23 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Tue, 15 Nov 2011 22:03:23 -0800 (PST) In-Reply-To: References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> Date: Wed, 16 Nov 2011 01:03:23 -0500 X-Google-Sender-Auth: oji7TpbNeCo5G4_u9GLv663jlM8 Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org" Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 06:03:27 -0000 On Wed, Nov 16, 2011 at 12:56 AM, Brian Dickson wrote: > On Wed, Nov 16, 2011 at 12:35 AM, Christopher Morrow > wrote: >> you may be willing to do same, you may also be willing to do this in >> the case of internal services routes that you don't actually want >> externally visible. > > Sure - and locally significant signatures/trust-anchors are very > important for just such an occasion. > (For any convenient value of "local", it should be noted. City, zip > code, province, continent, building, whatever.) yup, agreed. >> >> re-announcement is 'harder' since it's not clear if NTT is supposed to >> be passing cogent aol's routes or not, is it? > > Agreed - I can't be specific on exactly when, but expect me to present something > "real soon now" on a nuts-and-bolts level of how to do this. Maybe a > month, maybe two. look forward to it! I wonder actually if some on-going survey of routing data could help to inform when a 'leak' happens... I suspect this is what cyclops/etc are doing (identifying normal 'status' of routes between networks), I'm not clear on how useful this would be in the end though, my experience with cyclops/etc haven't been useful so far :( -chris From danny@tcb.net Tue Nov 15 22:20:56 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207FE11E8116 for ; Tue, 15 Nov 2011 22:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.024 X-Spam-Level: X-Spam-Status: No, score=-102.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soxmtEpN4G0j for ; Tue, 15 Nov 2011 22:20:55 -0800 (PST) Received: from uu.ops-netman.net (morrowc-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:36e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 42C2311E80E0 for ; Tue, 15 Nov 2011 22:20:55 -0800 (PST) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [208.76.12.119]) by uu.ops-netman.net (Postfix) with ESMTP id D47491900B3 for ; Wed, 16 Nov 2011 06:20:54 +0000 (UTC) Received: from [IPv6:2001:df8::16:3615:9eff:fe93:4d6f] (unknown [IPv6:2001:df8:0:16:3615:9eff:fe93:4d6f]) (Authenticated sender: danny@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 1ABDC320283 for ; Wed, 16 Nov 2011 06:20:51 +0000 (UTC) From: Danny McPherson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2011 01:20:49 -0500 Message-Id: <592AE37A-2FD1-4B2C-9326-B7800C5B4200@tcb.net> To: sidr wg list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [sidr] MISREF in draft-ietf-sidr-rpki-rtr-19 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 06:20:56 -0000 Just a trivial nit: s/RFC2385/RFC5926/ Was re-reviewing RPKI/RTR Cache Protocol and saw this error, might want = to fix: "It is expected that, when TCP-AO [RFC2385]is available on all platforms deployed by operators, it will become the mandatory to implement transport." -danny From touch@isi.edu Tue Nov 15 22:24:15 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD3921F92AA for ; Tue, 15 Nov 2011 22:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.039 X-Spam-Level: X-Spam-Status: No, score=-103.039 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjvsI1Ay-U63 for ; Tue, 15 Nov 2011 22:24:11 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5349A11E80E0 for ; Tue, 15 Nov 2011 22:24:11 -0800 (PST) Received: from [130.129.23.239] (dhcp-17ef.meeting.ietf.org [130.129.23.239]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id pAG6NcS0002534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Nov 2011 22:23:50 -0800 (PST) Message-ID: <4EC356E7.3040800@isi.edu> Date: Tue, 15 Nov 2011 22:23:35 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Danny McPherson References: <592AE37A-2FD1-4B2C-9326-B7800C5B4200@tcb.net> In-Reply-To: <592AE37A-2FD1-4B2C-9326-B7800C5B4200@tcb.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: sidr wg list Subject: Re: [sidr] MISREF in draft-ietf-sidr-rpki-rtr-19 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 06:24:15 -0000 RFC5925 is TCP-AO 5926 is the algorithms used by AO, not the AO mods to TCP Joe On 11/15/2011 10:20 PM, Danny McPherson wrote: > > Just a trivial nit: > > s/RFC2385/RFC5926/ > > Was re-reviewing RPKI/RTR Cache Protocol and saw this error, might want to fix: > > "It is expected that, when TCP-AO [RFC2385]is available on all > platforms deployed by operators, it will become the mandatory to > implement transport." > > -danny > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From danny@tcb.net Tue Nov 15 22:28:49 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABEFD11E814C for ; Tue, 15 Nov 2011 22:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.216 X-Spam-Level: X-Spam-Status: No, score=-102.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U04xU8nblSZn for ; Tue, 15 Nov 2011 22:28:49 -0800 (PST) Received: from uu.ops-netman.net (morrowc-1-pt.tunnel.tserv13.ash1.ipv6.he.net [IPv6:2001:470:7:36e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 41E0311E8113 for ; Tue, 15 Nov 2011 22:28:49 -0800 (PST) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [208.76.12.119]) by uu.ops-netman.net (Postfix) with ESMTP id DDE871901D4; Wed, 16 Nov 2011 06:28:48 +0000 (UTC) Received: from [IPv6:2001:df8::16:3615:9eff:fe93:4d6f] (unknown [IPv6:2001:df8:0:16:3615:9eff:fe93:4d6f]) (Authenticated sender: danny@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id CBFFA320245; Wed, 16 Nov 2011 06:28:47 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <4EC356E7.3040800@isi.edu> Date: Wed, 16 Nov 2011 01:28:42 -0500 Content-Transfer-Encoding: 7bit Message-Id: <1E0BE1D2-5F76-468C-84A1-05EF53C535A7@tcb.net> References: <592AE37A-2FD1-4B2C-9326-B7800C5B4200@tcb.net> <4EC356E7.3040800@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] MISREF in draft-ietf-sidr-rpki-rtr-19 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 06:28:49 -0000 Oops, yea, just noticed that -- thanks for [re]clarifying :-) -danny On Nov 16, 2011, at 1:23 AM, Joe Touch wrote: > RFC5925 is TCP-AO > > 5926 is the algorithms used by AO, not the AO mods to TCP From elisa@llnw.com Tue Nov 15 23:14:25 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146C611E81E7 for ; Tue, 15 Nov 2011 23:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJrKaSXwIFxF for ; Tue, 15 Nov 2011 23:14:24 -0800 (PST) Received: from mail.llnw.net (cmail.phx3.llnw.net [69.28.132.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8346211E81E3 for ; Tue, 15 Nov 2011 23:14:24 -0800 (PST) Received: (qmail 17520 invoked by uid 1008); 16 Nov 2011 00:14:22 -0700 Received: from 61-220-70-183.hinet-ip.hinet.net (HELO ?192.168.101.30?) (ejasinska@limelightnetworks.com@61.220.70.183) by mail.llnw.net with AES128-SHA encrypted SMTP; 16 Nov 2011 00:14:22 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Elisa Jasinska In-Reply-To: Date: Wed, 16 Nov 2011 15:14:20 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <00ABE7DA-65B9-4D9E-B4C4-0948351CCB31@llnw.com> References: To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: Elisa Jasinska , sidr@ietf.org Subject: Re: [sidr] transparent route-servers question(s) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 07:14:25 -0000 On Nov 15, 2011, at 14:36 , Randy Bush wrote: >> "Some route servers don't have an ASN, some use a private-asn" >=20 > i have had a small visit by a clue bat. if two RSs use AS 65666, > where is the cert for that AS? oops! Indeed! Using a private ANS for route server operations is neither = recommended nor encouraged in the IX community, although it is not = strictly forbidden either. Especially small IXPs (read: a switch in the = corner) operated by an organization not involved into routing otherwise = and therefore not even in possession of an AS number, might fall back on = this option. I don't recall an example out of the top of my head, will = do some digging and report back. Thanks Elisa =20 --=20 Elisa Jasinska Limelight Networks e elisa@llnw.com p +1 602 850 5753 m +31 6 23234891 From kent@bbn.com Tue Nov 15 23:51:00 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF5611E8138 for ; Tue, 15 Nov 2011 23:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9Pdk2OKYKKK for ; Tue, 15 Nov 2011 23:50:59 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id ABDD411E80F9 for ; Tue, 15 Nov 2011 23:50:59 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:58531 helo=[130.129.18.170]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RQaGn-000AwU-KU; Wed, 16 Nov 2011 02:50:58 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> References: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> Date: Wed, 16 Nov 2011 02:50:53 -0500 To: Danny McPherson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Origin Ops, TALs and Local TAs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 07:51:00 -0000 Danny, >Rob/Steve, et al., >Relative to the SIDR Origin Ops draft and local trust anchor (LTA) >configuration, I'm trying to understand how one would actualize >trust anchor locators (TALs) and LTAs in a deployment scenario and >was hoping you could help me here. A TAL points to a self-signed RPKI cert, which contains a 3779 extension that describes all of the address space under that cert. It also has an SIA extension that points to the repository publication point where one begins retrieval of other RPKI certs, etc. >I think it's probably safe to assume everyone is going to have a >"Constraints" file for some things. The local TA mechanism specifies that capability, but we've been told that most folks will find it too hard to manage that capability correctly. >Because the TALs don't actually specify the list of resources covered by >the referenced self-signed CA certificates the relying party must consult >each trust anchor (e.g., RIR) to determine the INR extension(s) within this >certificate, and the onus is on the RP to resolve conflicts, is this correct? the TAL doesn't but the cert to which it points does. If one uses a TAL for IANA (consistent with the IAB recommendation that you helped author), then 3779 processing will catch conflicts. > For example, currently, in the experimental pilot RPKI system many of the >INRs are asserting 0.0.0.0/0 and 0::/0, which opens the opportunity for >conflicts that must be resolved by the RP, when they likely have no real >capability to do this (hence the IAB statement on this topic). Agreed that an RIR claiming 0/0 is bad. I think this is holdover from the pre-TAL TA model. Hopefully this will go away. >Here's my primary question. If I wanted to form a 'federation' of sorts for >resiliency would I have to use additional TALs in conjunction with my >LTA and paracertificate hierarchy? If so, can an RP include some sort of >filter to constrain what a TA can assert as within their resource holdings? not sure what a federation is, but, yes, an RP can constrain what a TA is allowed to assert, via a constraints file. >That is, because for LTA to work every relying party in the transaction >path (i.e., source and destination networks, as well as intermediate RPs) >would need to override the putative [global] TA RPKI for every other >operators resources and generate a paracertificate hierarchy therein, >is that right? I don't understand all of the words above. >And if that's the case, wouldn't it be simpler for RPs to be able to >associate resources with each trust anchor rather than trusting them to >convey to the RP what resources they are authoritative for? LTA management allows this, but it becomes very complex to do well if there are too many data items to manage. Steve From randy@psg.com Wed Nov 16 01:15:52 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494B421F94D6 for ; Wed, 16 Nov 2011 01:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4ZrsO9xYRqH for ; Wed, 16 Nov 2011 01:15:50 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id D92D521F94CF for ; Wed, 16 Nov 2011 01:15:50 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RQbai-0007oP-0O; Wed, 16 Nov 2011 09:15:36 +0000 Date: Wed, 16 Nov 2011 17:15:34 +0800 Message-ID: From: Randy Bush To: Danny McPherson In-Reply-To: <1E0BE1D2-5F76-468C-84A1-05EF53C535A7@tcb.net> References: <592AE37A-2FD1-4B2C-9326-B7800C5B4200@tcb.net> <4EC356E7.3040800@isi.edu> <1E0BE1D2-5F76-468C-84A1-05EF53C535A7@tcb.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] MISREF in draft-ietf-sidr-rpki-rtr-19 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 09:15:52 -0000 thanks From danny@tcb.net Wed Nov 16 01:54:21 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B94F21F9619 for ; Wed, 16 Nov 2011 01:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87SNsXULD87t for ; Wed, 16 Nov 2011 01:54:20 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id DC19121F9615 for ; Wed, 16 Nov 2011 01:54:20 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 5E05F268063; Wed, 16 Nov 2011 02:54:20 -0700 (MST) Received: from dhcp-1267.meeting.ietf.org (dhcp-1267.meeting.ietf.org [130.129.18.103]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Wed, 16 Nov 2011 02:54:19 -0700 (MST) (envelope-from danny@tcb.net) From: Danny McPherson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2011 04:54:01 -0500 References: <20111116095300.22121.699.idtracker@ietfa.amsl.com> To: sidr wg list Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [sidr] Fwd: I-D Action: draft-foo-sidr-simple-leak-attack-bgpsec-no-help-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 09:54:21 -0000 =09 FYI - per request in SIDR yesterday.. -danny Begin forwarded message: > From: internet-drafts@ietf.org > Date: November 16, 2011 4:53:00 AM EST > To: i-d-announce@ietf.org > Subject: I-D Action: = draft-foo-sidr-simple-leak-attack-bgpsec-no-help-00.txt > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Route Leak Attacks Against BGPSEC > Author(s) : Danny McPherson > Shane Amante > Filename : = draft-foo-sidr-simple-leak-attack-bgpsec-no-help-00.txt > Pages : 8 > Date : 2011-11-16 >=20 > This document describes a very simple attack vector that illustrates > how RPKI-enabled BGPSEC machinery as currently defined can be easily > circumvented in order to launch a Man In The Middle (MITM) attack = via > BGP. It is meant to serve as input to the SIDR WG during routing > security requirements specification and discussions, and secure > routing protocol designs. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-foo-sidr-simple-leak-attack-bgps= ec-no-help-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-foo-sidr-simple-leak-attack-bgpse= c-no-help-00.txt >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From terry.manderson@icann.org Wed Nov 16 03:14:43 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2780021F955E for ; Wed, 16 Nov 2011 03:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.582 X-Spam-Level: X-Spam-Status: No, score=-106.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVDrP5bFXZFr for ; Wed, 16 Nov 2011 03:14:42 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id A07D721F9534 for ; Wed, 16 Nov 2011 03:14:42 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 16 Nov 2011 03:14:39 -0800 From: Terry Manderson To: Danny McPherson Date: Wed, 16 Nov 2011 03:14:34 -0800 Thread-Topic: [sidr] Fwd: I-D Action: draft-foo-sidr-simple-leak-attack-bgpsec-no-help-00.txt Thread-Index: AcykUO15RSPuTGscSa6gLr9l1iLK8g== Message-ID: <3D7CB6AC-5AAE-4FFE-8CBA-B13A9B0B9AF2@icann.org> References: <20111116095300.22121.699.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] Fwd: I-D Action: draft-foo-sidr-simple-leak-attack-bgpsec-no-help-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 11:14:43 -0000 Nice draft for a definition of "route leak". =20 Tiny nit. You typo'd voila. ;) Cheers, Terry On 16/11/2011, at 5:54 PM, "Danny McPherson" wrote: > =20 > FYI - per request in SIDR yesterday.. >=20 > -danny >=20 >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Date: November 16, 2011 4:53:00 AM EST >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-foo-sidr-simple-leak-attack-bgpsec-no-help-00= .txt >> Reply-To: internet-drafts@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >>=20 >> Title : Route Leak Attacks Against BGPSEC >> Author(s) : Danny McPherson >> Shane Amante >> Filename : draft-foo-sidr-simple-leak-attack-bgpsec-no-help-00= .txt >> Pages : 8 >> Date : 2011-11-16 >>=20 >> This document describes a very simple attack vector that illustrates >> how RPKI-enabled BGPSEC machinery as currently defined can be easily >> circumvented in order to launch a Man In The Middle (MITM) attack via >> BGP. It is meant to serve as input to the SIDR WG during routing >> security requirements specification and discussions, and secure >> routing protocol designs. >>=20 >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-foo-sidr-simple-leak-attack-bg= psec-no-help-00.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-foo-sidr-simple-leak-attack-bgp= sec-no-help-00.txt >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From eosterweil@verisign.com Wed Nov 16 03:16:49 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB2721F965F for ; Wed, 16 Nov 2011 03:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjoxxM6uZ8zh for ; Wed, 16 Nov 2011 03:16:49 -0800 (PST) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id E270D21F965C for ; Wed, 16 Nov 2011 03:16:27 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKTsOba44EFEq/vyOWu7sgs3rXTlT4/7vo@postini.com; Wed, 16 Nov 2011 03:16:49 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id pAGBFt90022238; Wed, 16 Nov 2011 06:15:55 -0500 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 06:15:55 -0500 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 06:15:54 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.01.0323.003; Wed, 16 Nov 2011 06:15:54 -0500 From: "Osterweil, Eric" To: "'terry.manderson@icann.org'" , "'danny@tcb.net'" Thread-Topic: [sidr] Fwd: I-D Action: draft-foo-sidr-simple-leak-attack-bgpsec-no-help-00.txt Thread-Index: AQHMpFDzfJyHV38ZUU2WsioI5u/4dZWvWZKK Date: Wed, 16 Nov 2011 11:15:52 +0000 Message-ID: In-Reply-To: <3D7CB6AC-5AAE-4FFE-8CBA-B13A9B0B9AF2@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.13.174] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Nov 2011 11:15:54.0830 (UTC) FILETIME=[1B8AF6E0:01CCA451] Cc: "'sidr@ietf.org'" Subject: Re: [sidr] Fwd: I-D Action: draft-foo-sidr-simple-leak-attack-bgpsec-no-help-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 11:16:50 -0000 Oooooooooh... Now I get it, thnx! Eric ----- Original Message ----- From: Terry Manderson [mailto:terry.manderson@icann.org] Sent: Wednesday, November 16, 2011 06:14 AM=0A= To: Danny McPherson Cc: sidr wg list Subject: Re: [sidr] Fwd: I-D Action: draft-foo-sidr-simple-leak-attack-bgps= ec-no-help-00.txt Nice draft for a definition of "route leak". =20 Tiny nit. You typo'd voila. ;) Cheers, Terry On 16/11/2011, at 5:54 PM, "Danny McPherson" wrote: > =20 > FYI - per request in SIDR yesterday.. >=20 > -danny >=20 >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Date: November 16, 2011 4:53:00 AM EST >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-foo-sidr-simple-leak-attack-bgpsec-no-help-00= .txt >> Reply-To: internet-drafts@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >>=20 >> Title : Route Leak Attacks Against BGPSEC >> Author(s) : Danny McPherson >> Shane Amante >> Filename : draft-foo-sidr-simple-leak-attack-bgpsec-no-help-00= .txt >> Pages : 8 >> Date : 2011-11-16 >>=20 >> This document describes a very simple attack vector that illustrates >> how RPKI-enabled BGPSEC machinery as currently defined can be easily >> circumvented in order to launch a Man In The Middle (MITM) attack via >> BGP. It is meant to serve as input to the SIDR WG during routing >> security requirements specification and discussions, and secure >> routing protocol designs. >>=20 >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-foo-sidr-simple-leak-attack-bg= psec-no-help-00.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-foo-sidr-simple-leak-attack-bgp= sec-no-help-00.txt >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From russw@riw.us Wed Nov 16 16:48:58 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F335C21F8CF3 for ; Wed, 16 Nov 2011 16:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYcnDn2nspJk for ; Wed, 16 Nov 2011 16:48:57 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 6B75D21F8CE3 for ; Wed, 16 Nov 2011 16:48:57 -0800 (PST) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:49570 helo=[192.168.100.58]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RQq9u-0008Ku-9Z; Wed, 16 Nov 2011 19:48:54 -0500 Message-ID: <4EC459F0.9070200@riw.us> Date: Wed, 16 Nov 2011 19:48:48 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Jakob Heitz References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: "sidr@ietf.org" Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 00:48:58 -0000 > Does this now allow me to send passwords in the clear on the internet? 1. Protection means to know that the site you intend to get to is actually the site you reach. 2. Part of this protection requires protecting the routing system. 3. If you don't protect the routing system, then people are vulnerable to various attacks against their accounts on web sites they believe they can trust. Is it really that complex? What I see so far is: 1. SIDR has ruled out "knowing intentions." Without knowing intentions, you can't very well compare what you know to what you think you should know. 2. SIDR has ruled knowing what the actual state of the system currently is (well, at least we know what the system might have looked like a week or two ago, and maybe a new route has come along that isn't signed but that I should prefer over an already existing signed route, or perhaps...) If you don't know what the system is supposed to look like, then you don't know whether or not what you see is valid. Can you tell me what it is SIDR is actually securing? :-) Russ From christopher.morrow@gmail.com Wed Nov 16 17:17:54 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD1F21F86A6 for ; Wed, 16 Nov 2011 17:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.552 X-Spam-Level: X-Spam-Status: No, score=-103.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvYXZDGkymYB for ; Wed, 16 Nov 2011 17:17:53 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A3E3921F86A1 for ; Wed, 16 Nov 2011 17:17:53 -0800 (PST) Received: by ywt34 with SMTP id 34so469649ywt.31 for ; Wed, 16 Nov 2011 17:17:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xATBAP1f2rJHlnvrcrMyOtyxDKZIi40kRdKFHcAS6KI=; b=HoCG45aMs/9tW9k5Rj8iFYS910EQ1kIBzSV4V103MU+eVq7VKCq2IeRmSlNcBY2igu Lw6H/Fk2LpjnTgEAGKotpx0YxdhdAvw1SX+ECFe+fCQo6Z90cwT26KNLiMcUC/JoMmgj DsWMO8yCE6WBqzxsuwUBHyDvvMWqqvYMKru6k= MIME-Version: 1.0 Received: by 10.50.184.202 with SMTP id ew10mr37165035igc.48.1321492672058; Wed, 16 Nov 2011 17:17:52 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Wed, 16 Nov 2011 17:17:51 -0800 (PST) In-Reply-To: <4EC459F0.9070200@riw.us> References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> Date: Wed, 16 Nov 2011 20:17:51 -0500 X-Google-Sender-Auth: I1KbwWaRVxIbqb8cmp1axA8lAtM Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org" Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 01:17:54 -0000 On Wed, Nov 16, 2011 at 7:48 PM, Russ White wrote: > >> Does this now allow me to send passwords in the clear on the internet? > > 1. Protection means to know that the site you intend to get to is > actually the site you reach. > 2. Part of this protection requires protecting the routing system. > 3. If you don't protect the routing system, then people are vulnerable > to various attacks against their accounts on web sites they believe they > can trust. > > Is it really that complex? (not really aimed at russ) is the never-ending rathole of 'what are we trying to protect' really required on-list? I think the most simple case we care about is: "Is the routing system telling us what it is supposed to?" Or rephrased some: "Did the route injected at the source get faithfully reproduced down the line to the receiver?" I'd hope that leads us safer packets and traffic for all users of the network, but really debating if plaintext passwds are safe is far too deep in the weeds I think. > > What I see so far is: > > 1. SIDR has ruled out "knowing intentions." Without knowing intentions, > you can't very well compare what you know to what you think you should know. > > 2. SIDR has ruled knowing what the actual state of the system currently > is (well, at least we know what the system might have looked like a week > or two ago, and maybe a new route has come along that isn't signed but > that I should prefer over an already existing signed route, or > perhaps...) If you don't know what the system is supposed to look like, > then you don't know whether or not what you see is valid. > > Can you tell me what it is SIDR is actually securing? > > :-) > > Russ > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From russw@riw.us Wed Nov 16 17:27:09 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81B31F0C56 for ; Wed, 16 Nov 2011 17:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5ciNrEaAeK3 for ; Wed, 16 Nov 2011 17:27:09 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5CC1F0C51 for ; Wed, 16 Nov 2011 17:27:09 -0800 (PST) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:50244 helo=[192.168.100.58]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RQqks-000393-IH; Wed, 16 Nov 2011 20:27:06 -0500 Message-ID: <4EC462E9.7090103@riw.us> Date: Wed, 16 Nov 2011 20:27:05 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Christopher Morrow References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: "sidr@ietf.org" Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 01:27:10 -0000 >> Is it really that complex? > (not really aimed at russ) > > is the never-ending rathole of 'what are we trying to protect' really > required on-list? I think the most simple case we care about is: "Is > the routing system telling us what it is supposed to?" Or rephrased > some: "Did the route injected at the source get faithfully reproduced > down the line to the receiver?" But SIDR is currently saying that as long as the route was injected correctly a week or two ago, "it's all good." Sorry, but I disagree. It's not "all good." Security compares what the state currently looks like to what the state should look like. If "what the state should look like" could be a week old, and you've ruled out "intentions" (which really rules out what the system should look like), then you've ruled out "security." Russ From randy@psg.com Wed Nov 16 17:44:18 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584C111E8082 for ; Wed, 16 Nov 2011 17:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1-FOvJBUcnb for ; Wed, 16 Nov 2011 17:44:17 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 7245711E8081 for ; Wed, 16 Nov 2011 17:44:17 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RQr1U-000Ac8-7c; Thu, 17 Nov 2011 01:44:16 +0000 Date: Thu, 17 Nov 2011 09:44:15 +0800 Message-ID: From: Randy Bush To: Russ White In-Reply-To: <4EC462E9.7090103@riw.us> References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 01:44:18 -0000 > Security compares what the state currently looks like to what the state > should look like. the problem is how does one know what the state of the system 'should' look like? randy From russw@riw.us Wed Nov 16 17:50:08 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABA21F0C57 for ; Wed, 16 Nov 2011 17:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fz9YtXmBtInS for ; Wed, 16 Nov 2011 17:50:07 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 868741F0C56 for ; Wed, 16 Nov 2011 17:50:07 -0800 (PST) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:50848 helo=[192.168.100.58]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RQr77-0002aT-Ng; Wed, 16 Nov 2011 20:50:05 -0500 Message-ID: <4EC4684B.3030204@riw.us> Date: Wed, 16 Nov 2011 20:50:03 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Randy Bush References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 01:50:08 -0000 >> Security compares what the state currently looks like to what the state >> should look like. > > the problem is how does one know what the state of the system 'should' > look like? My understanding has always been that the point of any security system is provide a secure and verifiable indication of what the system should look like in order to compare current events against that standard. For instance, could you secure an airport without some idea of who should be where and when they should be there? Or your house? How do you detect "attack traffic," in your network? By seeing things that shouldn't be there. If you don't know what it's supposed to look like, how can you tell what's not supposed to be there? In the same way, how can you "secure" the routing system without knowing what routes should be where --in other words, without knowing what everyone intended to advertise? Saying "it's okay if we know what it was supposed to look like a week ago," doesn't, IMHO, solve the problem at hand. :-) Russ From robert@raszuk.net Wed Nov 16 17:57:43 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3511F0C6D for ; Wed, 16 Nov 2011 17:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6JjiNfsQy2D for ; Wed, 16 Nov 2011 17:57:43 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 09CBA1F0C64 for ; Wed, 16 Nov 2011 17:57:43 -0800 (PST) Received: (qmail 22831 invoked by uid 399); 17 Nov 2011 01:57:42 -0000 Received: from unknown (HELO ?130.129.19.9?) (130.129.19.9) by mail1310.opentransfer.com with ESMTP; 17 Nov 2011 01:57:42 -0000 X-Originating-IP: 130.129.19.9 Message-ID: <4EC46A16.7010109@raszuk.net> Date: Thu, 17 Nov 2011 02:57:42 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Russ White References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> <4EC4684B.3030204@riw.us> In-Reply-To: <4EC4684B.3030204@riw.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 01:57:43 -0000 Hi Russ, I think the current intention is to secure the network on the basis of giving each prefix a badge and just check it at entrance door readers to each AS. If it is allowed in it enters if it is determined by the security back-end to be evil it is denied. I am not sure if you actually need to know who should be in or not at any given time if the backend provides the correct rules based on the badge readings. Of course the assumption is that HR distributed the badges correctly in the first place ;) R. >>> Security compares what the state currently looks like to what the state >>> should look like. >> >> the problem is how does one know what the state of the system 'should' >> look like? > > My understanding has always been that the point of any security system > is provide a secure and verifiable indication of what the system should > look like in order to compare current events against that standard. For > instance, could you secure an airport without some idea of who should be > where and when they should be there? Or your house? > > How do you detect "attack traffic," in your network? By seeing things > that shouldn't be there. If you don't know what it's supposed to look > like, how can you tell what's not supposed to be there? In the same way, > how can you "secure" the routing system without knowing what routes > should be where --in other words, without knowing what everyone intended > to advertise? Saying "it's okay if we know what it was supposed to look > like a week ago," doesn't, IMHO, solve the problem at hand. > > :-) > > Russ > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > From randy@psg.com Wed Nov 16 18:01:05 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E084B1F0C64 for ; Wed, 16 Nov 2011 18:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKtlOOzSCWEY for ; Wed, 16 Nov 2011 18:01:05 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 881F81F0C44 for ; Wed, 16 Nov 2011 18:01:05 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RQrHl-000AgG-82; Thu, 17 Nov 2011 02:01:05 +0000 Date: Thu, 17 Nov 2011 10:01:04 +0800 Message-ID: From: Randy Bush To: Russ White In-Reply-To: <4EC4684B.3030204@riw.us> References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> <4EC4684B.3030204@riw.us> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 02:01:06 -0000 hi russ, >>> Security compares what the state currently looks like to what the state >>> should look like. >> the problem is how does one know what the state of the system 'should' >> look like? > > My understanding has always been that the point of any security system > is provide a secure and verifiable indication of what the system should > look like in order to compare current events against that standard. you have been saying that for years. and i understand your point. what i have never understood is *how* you can tell how things 'should' be. so the current sidr proposals are for what we *know how to do.* they are not perfect, but they are a radical improvement on the current state. i am very open to clue on how to rigorously define how things 'should' be, especially if it is rigorously testable given real world constraints. randy From brian.peter.dickson@gmail.com Wed Nov 16 18:04:49 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0516821F8663 for ; Wed, 16 Nov 2011 18:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTiV8VgWlYzH for ; Wed, 16 Nov 2011 18:04:48 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0745921F86FF for ; Wed, 16 Nov 2011 18:04:47 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so1590733bkb.31 for ; Wed, 16 Nov 2011 18:04:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZjCoCaQCi9XZe/+RoACSzDUPZUGbT0FoVy5xS/1EKAE=; b=Dcyo0Z9pUIRalUmHQIGmqiSFa2rFvwmQLIN7FLUI1EZ+SmWWz3+IQTM9KvPShtG/u4 GUC6L7ygWNH4SW6HANLvDehVM6ExyLALnLZIjLCwbzfz6nZZx0dZYVhAv8gQeXV8X6tG AiOnUQdK7U3L20lldyX801ksgw/Ncu7zQ5a28= MIME-Version: 1.0 Received: by 10.205.119.207 with SMTP id fv15mr31518925bkc.100.1321495487108; Wed, 16 Nov 2011 18:04:47 -0800 (PST) Received: by 10.223.54.15 with HTTP; Wed, 16 Nov 2011 18:04:46 -0800 (PST) In-Reply-To: <4EC46A16.7010109@raszuk.net> References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> <4EC4684B.3030204@riw.us> <4EC46A16.7010109@raszuk.net> Date: Wed, 16 Nov 2011 21:04:46 -0500 Message-ID: From: Brian Dickson To: robert@raszuk.net Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 02:04:49 -0000 On Wed, Nov 16, 2011 at 8:57 PM, Robert Raszuk wrote: > Hi Russ, > > I think the current intention is to secure the network on the basis of > giving each prefix a badge and just check it at entrance door readers to > each AS. > > If it is allowed in it enters if it is determined by the security back-end > to be evil it is denied. That analogy works for packets. It doesn't work for routes. Routing sucks. Routes attract traffic. I would instead say, it's like a work order to install a window or door. That someone with a work order got as far as they did, is either proof that they are supposed to be there, or a security vulnerability, or maybe both. Signed work orders suggest that a window or door was requisitioned. It doesn't necessarily confirm which wall it should go in - the one to the next suite, the one to the vault, or the one to the street? But, chasing analogies to their breaking point isn't necessarily constructive. Yes, knowing what is intended is necessary if we want to provide security, as opposed to merely vague assurance. Given the amount of work expended thus far, taking the extra step (which may not be large) is both advisable, and something IMNSHO should be considered in-scope.... Brian From robert@raszuk.net Wed Nov 16 18:11:15 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8581F0C81 for ; Wed, 16 Nov 2011 18:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ebs-R0CAWCn5 for ; Wed, 16 Nov 2011 18:11:14 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 354DA21F8B50 for ; Wed, 16 Nov 2011 18:11:14 -0800 (PST) Received: (qmail 31266 invoked by uid 399); 17 Nov 2011 02:10:57 -0000 Received: from unknown (HELO ?130.129.19.9?) (130.129.19.9) by mail1310.opentransfer.com with ESMTP; 17 Nov 2011 02:10:57 -0000 X-Originating-IP: 130.129.19.9 Message-ID: <4EC46D32.8080908@raszuk.net> Date: Thu, 17 Nov 2011 03:10:58 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Brian Dickson References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> <4EC4684B.3030204@riw.us> <4EC46A16.7010109@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 02:11:15 -0000 Brian, > Given the amount of work expended thus far, taking the extra step > (which may not be large) is both advisable, and something IMNSHO > should be considered in-scope.... Sorry if I missed it but what is this extra step ? R. From randy@psg.com Wed Nov 16 18:16:02 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7501F0C81 for ; Wed, 16 Nov 2011 18:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0KXQ06sd-DQ for ; Wed, 16 Nov 2011 18:16:02 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED181F0C53 for ; Wed, 16 Nov 2011 18:16:02 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RQrWD-000AjC-AU; Thu, 17 Nov 2011 02:16:01 +0000 Date: Thu, 17 Nov 2011 10:16:00 +0800 Message-ID: From: Randy Bush To: Brian Dickson In-Reply-To: References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> <4EC4684B.3030204@riw.us> <4EC46A16.7010109@raszuk.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 02:16:02 -0000 > Yes, knowing what is intended is necessary if we want to provide > security, as opposed to merely vague assurance. > > Given the amount of work expended thus far, taking the extra step > (which may not be large) is both advisable, and something IMNSHO > should be considered in-scope.... i think we all agree. but talk is cheap. send formal definitions of intent and how to detect violations thereof. randy From eosterweil@verisign.com Wed Nov 16 19:07:54 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEE911E80DB for ; Wed, 16 Nov 2011 19:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpZlO4KQKvfK for ; Wed, 16 Nov 2011 19:07:53 -0800 (PST) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3133211E80CA for ; Wed, 16 Nov 2011 19:07:53 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKTsR6aCtnnD9tBY1168yBbYc1hXYpgIJi@postini.com; Wed, 16 Nov 2011 19:07:53 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id pAH37JGM023984; Wed, 16 Nov 2011 22:07:20 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.69]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 22:07:18 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Thu, 17 Nov 2011 11:07:08 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <855A62C6-6654-4FA8-8644-B7B044C76148@verisign.com> References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> <4EC4684B.3030204@riw.us> To: Randy Bush X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 17 Nov 2011 03:07:19.0325 (UTC) FILETIME=[048DA4D0:01CCA4D6] Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 03:07:54 -0000 On Nov 17, 2011, at 10:01 AM, Randy Bush wrote: > hi russ, >=20 >>>> Security compares what the state currently looks like to what the = state >>>> should look like. >>> the problem is how does one know what the state of the system = 'should' >>> look like? >>=20 >> My understanding has always been that the point of any security = system >> is provide a secure and verifiable indication of what the system = should >> look like in order to compare current events against that standard. >=20 > you have been saying that for years. and i understand your point. = what > i have never understood is *how* you can tell how things 'should' be. >=20 > so the current sidr proposals are for what we *know how to do.* they > are not perfect, but they are a radical improvement on the current > state. >=20 > i am very open to clue on how to rigorously define how things 'should' > be, especially if it is rigorously testable given real world > constraints. Maybe this discussion could be viewed as a good motivation for = revisiting the requirements draft. It seems to me that these arguments = (on both sides) could be viewed as the early stages of requirements = analysis (RA). If we can all get on the same page (or maybe into the = same chapter) about what we want to protect, then we can talk about how = to do it. In the event we discover that we've carved out an = unattainable requirement, we follow the exception back to RA and revisit = the requirements. Software engineering... :) Eric= From randy@psg.com Wed Nov 16 19:13:40 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF36511E80F5 for ; Wed, 16 Nov 2011 19:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWpLkCRtL9rA for ; Wed, 16 Nov 2011 19:13:39 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 7253811E80ED for ; Wed, 16 Nov 2011 19:13:39 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RQsPv-000As0-GO; Thu, 17 Nov 2011 03:13:35 +0000 Date: Thu, 17 Nov 2011 11:13:34 +0800 Message-ID: From: Randy Bush To: Eric Osterweil In-Reply-To: <855A62C6-6654-4FA8-8644-B7B044C76148@verisign.com> References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> <4EC4684B.3030204@riw.us> <855A62C6-6654-4FA8-8644-B7B044C76148@verisign.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 03:13:40 -0000 > Maybe this discussion could be viewed as a good motivation for > revisiting the requirements draft. don't require what you have no solid idea of how to achieve. randy From kent@bbn.com Wed Nov 16 19:26:28 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1089F1F0CC5 for ; Wed, 16 Nov 2011 19:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.537 X-Spam-Level: X-Spam-Status: No, score=-106.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYSjvu6Tr8n5 for ; Wed, 16 Nov 2011 19:26:27 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 86C491F0CA5 for ; Wed, 16 Nov 2011 19:26:27 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:53555 helo=[172.20.1.65]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RQscL-000Nxa-HX; Wed, 16 Nov 2011 22:26:26 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4EC4684B.3030204@riw.us> References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se > <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se > <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se > <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se > <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se > <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se > <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> <4EC4684B.3030204@riw.us> Date: Wed, 16 Nov 2011 22:25:31 -0500 To: Russ White From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 03:26:28 -0000 At 8:50 PM -0500 11/16/11, Russ White wrote: > >> Security compares what the state currently looks like to what the state >>> should look like. >> >> the problem is how does one know what the state of the system 'should' >> look like? > >My understanding has always been that the point of any security system >is provide a secure and verifiable indication of what the system should >look like in order to compare current events against that standard. The usual characterization of a secruity system is a set of mechanisms that are intended to enforce a secruity policy. Only if the policy articulates what the system "should look like" would your definition be congruent. Most security policies focus on aspects of system operation that are perceived as "secruity critical." The WG charter articulates a security policy, focusing on origin validation and path authenticity. These aspects of routing security are visible and this avoid the more problematic question of what the system "should look like." Steve From russw@riw.us Wed Nov 16 20:06:21 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E30F11E80ED for ; Wed, 16 Nov 2011 20:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVTQyGNuh4sV for ; Wed, 16 Nov 2011 20:06:20 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 790AC11E80B0 for ; Wed, 16 Nov 2011 20:06:20 -0800 (PST) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:52673 helo=[192.168.100.58]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RQtEv-0003n6-0R; Wed, 16 Nov 2011 23:06:17 -0500 Message-ID: <4EC48834.9060805@riw.us> Date: Wed, 16 Nov 2011 23:06:12 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Randy Bush References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> <4EC4684B.3030204@riw.us> <855A62C6-6654-4FA8-8644-B7B044C76148@verisign.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 04:06:21 -0000 >> Maybe this discussion could be viewed as a good motivation for >> revisiting the requirements draft. > > don't require what you have no solid idea of how to achieve. Maybe if someone actually laid out real requirements, someone, someplace, could determine how to achieve most (if not all) of them. The process SIDR has used is backwards --choose a solution, then build the requirements around that solution. When problems arise, just change the requirements so it's no longer a problem. :-) Russ From danny@tcb.net Wed Nov 16 20:24:35 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBC411E80F5 for ; Wed, 16 Nov 2011 20:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0-jh1WVged1 for ; Wed, 16 Nov 2011 20:24:34 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id BB5BE11E80F3 for ; Wed, 16 Nov 2011 20:24:34 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 8092B268081; Wed, 16 Nov 2011 21:24:24 -0700 (MST) Received: from dhcp-1267.meeting.ietf.org (dhcp-1267.meeting.ietf.org [130.129.18.103]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Wed, 16 Nov 2011 21:24:24 -0700 (MST) (envelope-from danny@tcb.net) From: Danny McPherson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2011 23:23:28 -0500 References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> To: sidr wg list Message-Id: <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [sidr] Route Leaks and BGP Security X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 04:24:35 -0000 =09 Team,=20 I've updated this draft based on some feedback received already. Given=20= the discussion at the WG session, and the list discussion as of late, = I'd like=20 to ask that it become a WG item and used to inform the BGP Threat Model=20= document -- particularly with regards to what's an acceptable residual = risk and=20 what is not. Once that's comprehensive it can be used to inform secure = routing=20 requirements documents in the working group, and then we can begin = assessing=20 the feasibility of reducing various risks. = Thanks! -danny Begin forwarded message: > From: internet-drafts@ietf.org > Date: November 16, 2011 11:01:24 PM EST > To: i-d-announce@ietf.org > Subject: I-D Action: = draft-foo-sidr-simple-leak-attack-bgpsec-no-help-01.txt > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Route Leak Attacks Against BGPSEC > Author(s) : Danny McPherson > Shane Amante > Filename : = draft-foo-sidr-simple-leak-attack-bgpsec-no-help-01.txt > Pages : 5 > Date : 2011-11-16 >=20 > This document describes a very simple attack vector that illustrates > how RPKI-enabled BGPSEC machinery as currently defined can be easily > circumvented in order to launch a Man In The Middle (MITM) attack = via > BGP. It is meant to serve as input to the IETF's Secure = Inter-Domain > Routing working group during routing security requirements > discussions and subsequent specification. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-foo-sidr-simple-leak-attack-bgps= ec-no-help-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-foo-sidr-simple-leak-attack-bgpse= c-no-help-01.txt >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From russw@riw.us Wed Nov 16 20:27:48 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17B211E810E for ; Wed, 16 Nov 2011 20:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAS5OQffY4je for ; Wed, 16 Nov 2011 20:27:48 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 2316211E80F5 for ; Wed, 16 Nov 2011 20:27:48 -0800 (PST) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:53175 helo=[192.168.100.58]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RQtZi-0000es-3a; Wed, 16 Nov 2011 23:27:46 -0500 Message-ID: <4EC48D37.9050005@riw.us> Date: Wed, 16 Nov 2011 23:27:35 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Stephen Kent References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se > <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se > <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se > <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se > <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se > <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> <4EC4684B.3030204@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 04:27:48 -0000 > Most security policies focus on aspects of system operation that are > perceived as "secruity critical." The WG charter articulates a security > policy, focusing on origin validation and path authenticity. These > aspects of routing security are visible and this avoid the more > problematic question of what the system "should look like." Path authenticity is a check of precisely what? What the AS Path should look like. Once you put timers in there, and then do lazy verification, and then do beacons, and then... You've left the realm of ensuring a received route has a "valid" AS Path from the perspective of what the AS Path should look like. It might have looked like that a week ago, but who knows what it should look like right now? As you even said: > The usual characterization of a secruity system is a set of mechanisms that > are intended to enforce a secruity policy. A policy is what someone, someplace, intends. What someone intends is simply an expression of "what the system should look like." You can't get away from intent. :-) Russ From russw@riw.us Wed Nov 16 20:32:39 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491C811E80C2 for ; Wed, 16 Nov 2011 20:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVf60TGg7j0s for ; Wed, 16 Nov 2011 20:32:38 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id C659111E80B0 for ; Wed, 16 Nov 2011 20:32:38 -0800 (PST) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:53228 helo=[192.168.100.58]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RQteM-0005Gi-WD; Wed, 16 Nov 2011 23:32:35 -0500 Message-ID: <4EC48E5E.4060203@riw.us> Date: Wed, 16 Nov 2011 23:32:30 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: robert@raszuk.net References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> <4EC4684B.3030204@riw.us> <4EC46A16.7010109@raszuk.net> In-Reply-To: <4EC46A16.7010109@raszuk.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 04:32:39 -0000 > I think the current intention is to secure the network on the basis of > giving each prefix a badge and just check it at entrance door readers to > each AS. Don't treat routing updates as packets. Routing protocols are distributed near real time databases, not applications that send and receive packets. > I am not sure if you actually need to know who should be in or not at > any given time if the backend provides the correct rules based on the > badge readings. Of course the assumption is that HR distributed the > badges correctly in the first place ;) But you see, that's intent. What we're trying to do is infer undefined intent (because we won't admit it's intent), from a rather loose and messy signature on the packet, combined with some timers that are set so far away from real time as to be almost useless (because it's too hard to secure route removal in a signed packet system). :-) Russ From kent@bbn.com Wed Nov 16 21:28:13 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AB121F9683 for ; Wed, 16 Nov 2011 21:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.538 X-Spam-Level: X-Spam-Status: No, score=-106.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOyr7SEsxdS9 for ; Wed, 16 Nov 2011 21:28:12 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id E655221F967E for ; Wed, 16 Nov 2011 21:28:11 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:57390 helo=[172.20.1.65]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RQuW7-000OfF-K4; Thu, 17 Nov 2011 00:28:09 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> <3F1388E3-A694-42C9-AE2F-F12BF15DC86F@verisign.com> Date: Thu, 17 Nov 2011 00:13:56 -0500 To: Brian Dickson From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-890614808==_ma============" Cc: "sidr@ietf.org list" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 05:28:13 -0000 --============_-890614808==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 10:25 PM -0500 11/13/11, Brian Dickson wrote: >On Sun, Nov 13, 2011 at 9:16 PM, Stephen Kent wrote: >> You suggested that we codify how the community should deal with problems >> that motivate delaying a phase transition. We're not writing the timeline >> document now, but the text at the beginning of this message is an effort to >> make sure such considerations are addressed in that document. > >When you say "timeline document", do you mean "timeline for specific >implementation of the phases in this document"? > >I ask because the algorithm-agility sure looks like a timeline document. I mean a document that associates dates with the phases described in the alg agility doc. I've reworded the agility doc to say "timetable" instead of "timeline" to try to avoid confusion. >... > >This statement is entirely predicated on having Phase 2, as it is currently >defined, after Phase 1 (CAs ready for receiving B) and before Phase 3 >(when RPs are able to validate using B). I don't see what this step >in this order, buys us, or even that it is necessary at all. Phase 1 allows early adopter CAs to get certs under the new alg suite, but does not require them to do a lot of work, because they don't have to issue new certs except for the children who ask for them. Phase 2 requires CAs to do this work, which enables RPs to test their RP software with the new alg, if they wish, i.e., another early adopter capability. Phase 3 says RP have to be able to do this. I think the order makes sense. >Let's take a look at what happens after Phase 3: >- RPs speak "B". >- CAs can process "B". This characterization strikes me as backwards. RPs process Suite B products. CAs generate Suite B products. CAs "process" requests for certs under Suite B. But, let's not quibble. The rest of your message argues that Phase 2 is unnecessary. But, you acknowledge the need for CAs and RPs to experiment with software that supports Suite B, and processes that support transition from A to B. Thart is precisely what Phase 2 enables. It gives RPs time to work on processing Suite B product sets, but it does not require that they do so. Also, if some CAs didn't get the Suite B product set generation right there is an opportunity to provide feedback, but Suite A products sets are still there, so things don't break. Trying to move from Phase 1 to Phase 3, as you suggest seems very likely to cause things to break, especially when coupled with the notion that a CA can decide to make use of only Suite B if it wishes. Steve --============_-890614808==_ma============ Content-Type: text/html; charset="us-ascii" Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03
At 10:25 PM -0500 11/13/11, Brian Dickson wrote:
On Sun, Nov 13, 2011 at 9:16 PM, Stephen Kent <kent@bbn.com> wrote:
> You suggested that we codify how the community should deal with problems
> that motivate delaying a phase transition. We're not writing the timeline
> document now, but the text at the beginning of this message is an effort to
> make sure such considerations are addressed in that document.

When you say "timeline document", do you mean "timeline for specific
implementation of the phases in this document"?

I ask because the algorithm-agility sure looks like a timeline document.

I mean a document that associates dates with the phases described in the
alg agility doc. I've reworded the agility doc to say "timetable" instead of "timeline" to try to avoid confusion.

...

This statement is entirely predicated on having Phase 2, as it is currently
defined, after Phase 1 (CAs ready for receiving B) and before Phase 3
(when RPs are able to validate using B). I don't see what this step
in this order, buys us, or even that it is necessary at all.

Phase 1 allows early adopter CAs to get certs under the new alg suite, but does not require them to do a lot of work, because they don't have to issue new certs except for the children who ask for them.

Phase 2 requires CAs to do this work, which enables RPs to test their RP software with the new alg, if they wish, i.e., another early adopter capability.

Phase 3 says RP have to be able to do this.

I think the order makes sense.

Let's take a look at what happens after Phase 3:
- RPs speak "B".
- CAs can process "B".

This characterization strikes me as backwards. RPs process Suite B products. CAs generate Suite B products. CAs "process" requests for certs under Suite B. But, let's not quibble.

The rest of your message argues that Phase 2 is unnecessary. But, you acknowledge the need for CAs and RPs to experiment with software that supports Suite B, and processes that support transition from A to B.  Thart is precisely what Phase 2 enables. It gives RPs time to work on processing Suite B product sets, but it does not require that they do so. Also, if some CAs didn't get the Suite B product set generation right there is an opportunity to provide feedback, but Suite A products sets are still there, so things don't break.  Trying to move from Phase 1 to Phase 3, as you suggest seems very likely to cause things to break, especially when coupled with the notion that a CA can decide to make use of only Suite B if it wishes.

Steve
--============_-890614808==_ma============-- From eosterweil@verisign.com Wed Nov 16 22:04:19 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583A111E80EF for ; Wed, 16 Nov 2011 22:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zi6aAW+RdhHd for ; Wed, 16 Nov 2011 22:04:18 -0800 (PST) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id F0A5711E80D1 for ; Wed, 16 Nov 2011 22:04:16 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKTsSjvu7K9vFd3+SIGGCKssYg5Px6xRB3@postini.com; Wed, 16 Nov 2011 22:04:17 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id pAH63fQ3025035; Thu, 17 Nov 2011 01:03:41 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.69]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 01:03:40 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <4EC48834.9060805@riw.us> Date: Thu, 17 Nov 2011 14:03:30 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2A0FB7C4-47D0-4E95-A209-BC0DE87DB501@verisign.com> References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> <4EC4684B.3030204@riw.us> <855A62C6-6654-4FA8-8644-B7B044C76148@verisign.com> <4EC48834.9060805@riw.us> To: Russ White X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 17 Nov 2011 06:03:41.0745 (UTC) FILETIME=[A82ACA10:01CCA4EE] Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 06:04:19 -0000 On Nov 17, 2011, at 12:06 PM, Russ White wrote: >=20 >>> Maybe this discussion could be viewed as a good motivation for >>> revisiting the requirements draft. >>=20 >> don't require what you have no solid idea of how to achieve. >=20 > Maybe if someone actually laid out real requirements, someone, > someplace, could determine how to achieve most (if not all) of them. = The > process SIDR has used is backwards --choose a solution, then build the > requirements around that solution. When problems arise, just change = the > requirements so it's no longer a problem. Totally agree w/ u here, Russ... Randy, we are all arguing over what we think a secure routing system = should do... It sounds like you (and your team?) have already decided = what you think everyone's requirements are, but it's pretty plain to all = that a fair number of people here in the wg do not agree. One of the = main reasons software systems begin with requirements analysis is = precisely so that we can know if our solution meets our needs. As I = said before, if we wind up needing to rework our collective = requirements, then so be it, but this process needs to be followed, not = skipped. Even your above comment has taken this out of order (skipping = a requirement because you think you can't do it implies a design = attempt); requirements come first... ;) Eric= From randy@psg.com Wed Nov 16 22:10:26 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A934621F8C10 for ; Wed, 16 Nov 2011 22:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0FBS+wLv5Go for ; Wed, 16 Nov 2011 22:10:26 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2277D21F9754 for ; Wed, 16 Nov 2011 22:10:26 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RQvB0-000BHa-EO; Thu, 17 Nov 2011 06:10:22 +0000 Date: Thu, 17 Nov 2011 14:10:21 +0800 Message-ID: From: Randy Bush To: Russ White In-Reply-To: <4EC48834.9060805@riw.us> <4EC48E5E.4060203@riw.us> <2A0FB7C4-47D0-4E95-A209-BC0DE87DB501@verisign.com> References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> <4EC4684B.3030204@riw.us> <855A62C6-6654-4FA8-8644-B7B044C76148@verisign.com> <4EC48834.9060805@riw.us> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 06:10:26 -0000 > The process SIDR has used is backwards --choose a solution, then build > the requirements around that solution. the bgpsec requirements document was started from the 2008 document draft-ietf-rpsec-bgpsecrec-10 randy From brian.peter.dickson@gmail.com Thu Nov 17 09:50:23 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8271B1F0C80 for ; Thu, 17 Nov 2011 09:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-wlKURZ4EX7 for ; Thu, 17 Nov 2011 09:50:22 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42F0E1F0C78 for ; Thu, 17 Nov 2011 09:50:22 -0800 (PST) Received: by faap16 with SMTP id p16so4814242faa.31 for ; Thu, 17 Nov 2011 09:50:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7RFYBVohO2uLNY0gAzK2eIEBx0+FfIPWfx7JhIfnvq0=; b=dk8iyhGtKLiGi7IbiwFCJcX5nL/De1rrCFIsSVFILHZVL9kSw5ghasacp5PqW+UH2O eXxxYb81r8YrYZEAQFaPRnocqrBi8UMCJVQD16D5t0HLUsFYOOh6+MuusMLdiIffJRF9 eDHuWjjmPtr2tSaIpoLJoPw7s9pz0IOy+1USs= MIME-Version: 1.0 Received: by 10.205.120.2 with SMTP id fw2mr26234720bkc.10.1321552221284; Thu, 17 Nov 2011 09:50:21 -0800 (PST) Received: by 10.223.54.15 with HTTP; Thu, 17 Nov 2011 09:50:20 -0800 (PST) In-Reply-To: References: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> <3F1388E3-A694-42C9-AE2F-F12BF15DC86F@verisign.com> Date: Thu, 17 Nov 2011 12:50:20 -0500 Message-ID: From: Brian Dickson To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org list" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 17:50:23 -0000 On Thu, Nov 17, 2011 at 12:13 AM, Stephen Kent wrote: > At 10:25 PM -0500 11/13/11, Brian Dickson wrote: > (when RPs are able to validate using B). I don't see what this step > in this order, buys us, or even that it is necessary at all. > > Phase 1 allows early adopter CAs to get certs under the new alg suite, bu= t > does not require them to do a lot of work, because they don't have to iss= ue > new certs except for the children who ask for them. > Phase 2 requires CAs to do this work, which enables RPs to test their RP > software with the new alg, if they wish, i.e., another early adopter > capability. Here's my point - you're employing a circular argument. Strictly speaking, there is no actual _need_ for CAs and RPs to _globally_ achieve this state, simply to do testing. CAs and RPs can (in more local environments) coordinate such testing. E.g. CAs can issue Suite B products, under a different cert than their "real" cert. RPs can configure the CA's "fake" cert as a trust anchor. More to the point - here is the only reason I can see to _require_ every CA to issue Suite B products (as a parallel chain of products): - To make possible the ending of Suite A deployment entirely Under phase 2, as defined, there are two cert trees. One where every cert i= s issued with a cert chain of AAAAAA..., and the other with BBBBB... What I'm saying, as a point of clarification, is that BBBBBB.... is not _strictly_ required for support for Suite B. And that "enabling Suite B" is distinct from "disabling Suite A". We may disagree on whether having more than one Suite available and deployed at a given time is wise. However, what I am trying to present is another deployment track: - Enable Suite B as early as possible, by enabling a less risky deployment - Being able to roll back to Suite A means there is less incumbent risk _to the issuer_ - There are two parties for whom risk is an issue, the RPs and the issuers. - The risks to be considered are, both the general stability of code doing RP validation, and the global propagation of prefixes - Under this alternate deployment scenario, at any point, a coordinated roll-back is still feasible. The later it happens, the more work is needed, but it is also more likely that early discovery of issues that require a roll-back will occur. > Phase 3 says RP have to be able to do this. > I think the order makes sense. > > Let's take a look at what happens after Phase 3: > - RPs speak "B". > > - CAs can process "B". > > This characterization strikes me as backwards. RPs process Suite B produc= ts. > CAs generate Suite B products. CAs "process" requests for certs under Sui= te > B. But, let's not quibble. Actually, it's not quibbling - this gets to the heart of the issue. I'm saying, "CAs are _able_ to 'process' requests _of_ Suite B", but this is orthogonal to the statement "CAs _must_ _issue_ Suite B products". What I'm saying is, regardless of the order of what was previously called "Phase N": Once the steps of Phase 1 and Phase 3 have been completed the following hol= d: - RPs are _able_ to process products which are of all 4 forms, involving Suite A and Suite B. This includes AA, AB, BA, and BB. - CAs _can_ generate Suite B products - CAs _can_ process requests under Suite B - Nobody is _required_ to do anything (in terms of issuing Suite B vs Suite= A) --- Of course, if a child requests a cert with PoP(B), the resulting cert must be issued accordingly --- The parent in this case would be equally free to issue either BB _xor_ AB material (depending on local CA policy) > The rest of your message argues that Phase 2 is unnecessary. But, you > acknowledge the need for CAs and RPs to experiment with software that > supports Suite B, and processes that support transition from A to B.=A0 T= hart > is precisely what Phase 2 enables. What I'm saying, if you look at the strict requirements for doing testing, is that the bullet points above meet _every_ requirement for any CA to issu= e a Suite B product and every RP have the ability to process the result. I.e. for post-experiment stages of real operational deployment. Once every RP is able to process Suite B, it is able to process heterogenou= s products that contain any combination of Suite A and Suite B material. I'm also saying that there is no _strict_ requirement for all-B cert chains= , to enable use of Suite B. Phase 2 is only necessary to require CAs not issue (and remove) any Suite A material, in order to end (globally) use of Suite B. NB: If we change the order, then Phase 2 can be subsumed by Phase 4. Phase 2 becomes moot. --- I'm also saying, that the overall strategy of supporting only one Suite under the steady-state, is being presented as an a priori assumption or requirement. I'd suggest that, given the coordination required, that the proportion of the time where only one Suite is permitted, may be less than the vast majority, and in fact may turn out to be the minority. It is worth at least considering, that if more of the time is spent with multiple signatures supported, whether the more flexible approach better fits the operation mode, and whether this in turn facilitates faster deployment of new Suites. The current approach is a "stick"-only approach. It mandates usage and migration with no benefit for early adoption. What I am suggesting is both "carrot" and "stick". It encourages adoption of the new Suite as well as discourages use of the old Suite. > Also, if some > CAs didn't get the Suite B product set generation right there is an > opportunity to provide feedback, but Suite A products sets are still ther= e, > so things don't break. Here's the thing - if all-A chains continue to exist until Phase 4, _and_ fallback to Suite A is required, this is a downgrade-attack vulnerability. Hybrid A/B chains do not suffer from that, so the comparative attack surface is shrinking over time, versus fixed in the current model. Given that the introduction of B and the elimination of A is an explicit goal, and the underlying assumption is that B is stronger than A, or even that A has some flaw or weakness, then adopting an approach which reduces that attack surface is tautologically superior. > Trying to move from Phase 1 to Phase 3, as you > suggest seems very likely to cause things to break, especially when coupl= ed > with the notion that a CA can decide to make use of only Suite B if it > wishes. Not so - recall, I am saying that Phase 3 is requiring the support for Suit= e B. The scope of a given CA using Suite B, is that CA and its descendants _only= _. The "things" in question are the _validation_ of signed announcements using Suite B. The whole agility document already presumes successful deployment of Suite = A. Suite A could only be considered successfully deployed if RPs correctly handle validation failures. Not requiring all-A or all-B, supports a self-organizing deployment process where sparse Suite B adoption is possible. This would be where a CA has comparatively few descendants using Suite B, and then converts to Suite B. Sparse adoption is necessary to enable early adopters to achieve all-B status (and excludes fallback-to-A). Not permitting sparse adoption means that the earliest that all-B can occur, is after the very last A user switches. The harm comes not from causing things to break, but from not allowing ROA-owners (leaf certificate holders) to protect their assets with the best available crypto that is widely supported. Brian From gih@apnic.net Thu Nov 17 16:19:50 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84BA11E80AE for ; Thu, 17 Nov 2011 16:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGFb5hAvKicS for ; Thu, 17 Nov 2011 16:19:50 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1E911E80AB for ; Thu, 17 Nov 2011 16:19:50 -0800 (PST) Received: from dhcp-4331.meeting.ietf.org (dhcp-4331.meeting.ietf.org [130.129.67.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 2B09DB6760; Fri, 18 Nov 2011 10:19:48 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Fri, 18 Nov 2011 11:19:54 +1100 Content-Transfer-Encoding: 7bit Message-Id: <09683D2C-A35A-4083-93D4-0E47B2106D83@apnic.net> References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> <4EC4684B.3030204@riw.us> <855A62C6-6654-4FA8-8644-B7B044C76148@verisign.com> <4EC48834.9060805@riw.us> To: Randy Bush X-Mailer: Apple Mail (2.1251.1) Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 00:19:51 -0000 On 17/11/2011, at 5:10 PM, Randy Bush wrote: >> The process SIDR has used is backwards --choose a solution, then build >> the requirements around that solution. > > the bgpsec requirements document was started from the 2008 document > draft-ietf-rpsec-bgpsecrec-10 That document never managed to reconcile the various views relating to AS Path validation, so I'm unclear if you are citing this as a completed activity, because to me it certainly appeared to be an incomplete piece of work. To be specific to quote from section 7 of this draft: AS_PATH Feasibility Check: The AS_PATH list may correspond to a valid list of autonomous systems according to the first verification category listed in the "Areas to Secure" Section above. Further study will determine the extent to which this is a security requirement. From christopher.morrow@gmail.com Thu Nov 17 22:21:13 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2740411E80B0 for ; Thu, 17 Nov 2011 22:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.553 X-Spam-Level: X-Spam-Status: No, score=-103.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBYtZZIrwrx7 for ; Thu, 17 Nov 2011 22:21:12 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0B411E8097 for ; Thu, 17 Nov 2011 22:21:12 -0800 (PST) Received: by iaeo4 with SMTP id o4so3945557iae.31 for ; Thu, 17 Nov 2011 22:21:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Qe/fYRtbKE90ZNB4q66laLo9bBs8t1kGZPrfS4xMoSU=; b=T9Ci5a3yvdFrdgf0uYT07hJGQGRJ9NUC/2uOG9cXrLoHn+f8l0B40jNEPg53npeemv ibYcIYuWctPEjLbjR1RQAjL9MSspLVoba7pL4o2N8fL2AQWfPgdHeJFCPG2abZtLedqH 0slSTi4DpXxZCcwm9Ub+WgHlleD3XlwOlJ30g= MIME-Version: 1.0 Received: by 10.42.176.130 with SMTP id be2mr6941icb.11.1321597272042; Thu, 17 Nov 2011 22:21:12 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Thu, 17 Nov 2011 22:21:11 -0800 (PST) In-Reply-To: References: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> <3F1388E3-A694-42C9-AE2F-F12BF15DC86F@verisign.com> Date: Fri, 18 Nov 2011 01:21:11 -0500 X-Google-Sender-Auth: ENM2pIcJzCW4Wzlz4TApa2LNbFA Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr@ietf.org list" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 06:21:13 -0000 On Thu, Nov 17, 2011 at 12:50 PM, Brian Dickson wrote: > Here's the thing - if all-A chains continue to exist until Phase 4, > _and_ fallback to Suite A is required, this is a downgrade-attack > vulnerability. > It seems to me that as long as there are consumers of cert material that can not do the 'new hotness' (B in your example) you will have to make products in the 'old and busted' form. Once everyone can do 'new hotness', there is a relatively short period of time required to kill off 'old and busted'. I don't think you can get away with not making 'old and busted' until everyone is able to plan ball, eh? -Chris From turners@ieca.com Thu Nov 17 23:19:19 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8772511E808F for ; Thu, 17 Nov 2011 23:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.97 X-Spam-Level: X-Spam-Status: No, score=-101.97 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_22=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sF+2P9XN8qtz for ; Thu, 17 Nov 2011 23:19:13 -0800 (PST) Received: from gateway.websitewelcome.com (gateway16.websitewelcome.com [69.56.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6127E11E808B for ; Thu, 17 Nov 2011 23:19:13 -0800 (PST) Received: by gateway.websitewelcome.com (Postfix, from userid 5007) id CFEED4185C0BB; Fri, 18 Nov 2011 01:18:05 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway.websitewelcome.com (Postfix) with ESMTP id C037E4185C064 for ; Fri, 18 Nov 2011 01:18:05 -0600 (CST) Received: from [130.129.37.148] (port=54191 helo=dhcp-2594.meeting.ietf.org) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RRIi4-0004o0-UW for sidr@ietf.org; Fri, 18 Nov 2011 01:18:05 -0600 Message-ID: <4EC606AC.3040309@ieca.com> Date: Fri, 18 Nov 2011 15:18:04 +0800 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: dhcp-2594.meeting.ietf.org [130.129.37.148]:54191 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [sidr] comments on BGPSEC PKI and Alg profiles X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 07:19:19 -0000 So I ran through my presentation at a million miles an hour, but I did get some comments. Here's what I think we ought to do to resolve them: - From Russ H.: just use cn don't use cn + sn in subject. Rob A. went and looked at the existing RPKI certs. cn+sn is used so we're going to leave it as is (i.e., cn+sn). - From Brian W.: question about EC IPR. We should really be pointing to RFC 6090 for ECDSA. I'd like to propose that we point there instead of FIPS 186-3. - From me: add an ASN.1 module for the BGPSEC EKU. I made others do it so I should do it too (i.e., eat my own dog food). I'll give people a couple of weeks to recover from the meeting before I post a new version. spt From turners@ieca.com Thu Nov 17 23:34:24 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C5311E80AA for ; Thu, 17 Nov 2011 23:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.261 X-Spam-Level: X-Spam-Status: No, score=-102.261 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZJng9MfnkQ4 for ; Thu, 17 Nov 2011 23:34:24 -0800 (PST) Received: from gateway.websitewelcome.com (gateway04.websitewelcome.com [67.18.22.81]) by ietfa.amsl.com (Postfix) with ESMTP id 05C7B11E808F for ; Thu, 17 Nov 2011 23:34:23 -0800 (PST) Received: by gateway.websitewelcome.com (Postfix, from userid 5007) id D766B3CA88A6C; Fri, 18 Nov 2011 01:34:22 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway.websitewelcome.com (Postfix) with ESMTP id CC7333CA88A48 for ; Fri, 18 Nov 2011 01:34:22 -0600 (CST) Received: from [130.129.37.148] (port=54313 helo=dhcp-2594.meeting.ietf.org) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RRIxp-0007tk-Uv for sidr@ietf.org; Fri, 18 Nov 2011 01:34:22 -0600 Message-ID: <4EC60A7D.3030306@ieca.com> Date: Fri, 18 Nov 2011 15:34:21 +0800 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "sidr@ietf.org list" References: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> <3F1388E3-A694-42C9-AE2F-F12BF15DC86F@verisign.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: dhcp-2594.meeting.ietf.org [130.129.37.148]:54313 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 07:34:24 -0000 On 11/18/11 2:21 PM, Christopher Morrow wrote: > On Thu, Nov 17, 2011 at 12:50 PM, Brian Dickson > wrote: > >> Here's the thing - if all-A chains continue to exist until Phase 4, >> _and_ fallback to Suite A is required, this is a downgrade-attack >> vulnerability. >> > > It seems to me that as long as there are consumers of cert material > that can not do the 'new hotness' (B in your example) you will have to > make products in the 'old and busted' form. Once everyone can do 'new > hotness', there is a relatively short period of time required to kill > off 'old and busted'. > > I don't think you can get away with not making 'old and busted' until > everyone is able to plan ball, eh? Hope of hopes here is that we don't just transition when an alg is broke. Algs weaken over time - that's just a fact. When we retire an alg because it doesn't cut it anymore, then running with the old unbroken alg is a downgrade but assuming the alg ain't broke then it's probably okay for the transition period. spt From ttauber@1-4-5.net Fri Nov 18 06:08:48 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7AD221F8AD1 for ; Fri, 18 Nov 2011 06:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-qPfJ+D2VUf for ; Fri, 18 Nov 2011 06:08:42 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9111121F84B1 for ; Fri, 18 Nov 2011 06:08:38 -0800 (PST) Received: by vbbfc26 with SMTP id fc26so224975vbb.31 for ; Fri, 18 Nov 2011 06:08:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.38.6 with SMTP id c6mr3821819vdk.73.1321625318097; Fri, 18 Nov 2011 06:08:38 -0800 (PST) Received: by 10.220.183.74 with HTTP; Fri, 18 Nov 2011 06:08:37 -0800 (PST) X-Originating-IP: [24.104.152.66] In-Reply-To: <09683D2C-A35A-4083-93D4-0E47B2106D83@apnic.net> References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> <4EC4684B.3030204@riw.us> <855A62C6-6654-4FA8-8644-B7B044C76148@verisign.com> <4EC48834.9060805@riw.us> <09683D2C-A35A-4083-93D4-0E47B2106D83@apnic.net> Date: Fri, 18 Nov 2011 09:08:37 -0500 Message-ID: From: Tony Tauber To: Geoff Huston Content-Type: multipart/alternative; boundary=bcaec51b984f9c844a04b202df6e Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 14:08:48 -0000 --bcaec51b984f9c844a04b202df6e Content-Type: text/plain; charset=ISO-8859-1 As that old draft's author/editor (started as editor, ended up more as author, with suggestions), perhaps I can add some clarification to some of what's being re-hashed here. It's likely many already understand it; some don't; some could be aided by different wording. Steve Kent takes the approach that working through the processing and propagation of updates and securing those operations to the spec. The notion appears to me to be to model behavior based on discrete events and the BGP FSM. Russ White takes the approach that the overall deployed system is very complex containing many dimensions of variability including but not limited to time, topology, and local practice/policy. Following from that is a concern that, beyond a point, adding the additional complexity being proposed results in either no benefit or negative impact to the goals of the global routing system. Hopefully I've characterized things reasonably and this might help anyone who's having trouble following at home. Tony On Thu, Nov 17, 2011 at 7:19 PM, Geoff Huston wrote: > > On 17/11/2011, at 5:10 PM, Randy Bush wrote: > > >> The process SIDR has used is backwards --choose a solution, then build > >> the requirements around that solution. > > > > the bgpsec requirements document was started from the 2008 document > > draft-ietf-rpsec-bgpsecrec-10 > > That document never managed to reconcile the various views relating to > AS Path validation, so I'm unclear if you are citing this as a completed > activity, because to me it certainly appeared to be an incomplete piece > of work. > > To be specific to quote from section 7 of this draft: > > AS_PATH Feasibility Check: The AS_PATH list may correspond to a > valid list of autonomous systems according to the first > verification category listed in the "Areas to Secure" Section > above. Further study will determine the extent to which this is a > security requirement. > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --bcaec51b984f9c844a04b202df6e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As that old draft's author/editor (started as editor, ended up more as = author, with suggestions),
perhaps I can add some clarification to some = of what's being re-hashed here.
It's likely many already underst= and it; some don't; some could be aided by different wording.

Steve Kent takes the approach that working through the processing and p= ropagation of updates
and securing those operations to the spec.=A0
= The notion appears to me to be to model behavior based on discrete events a= nd the BGP FSM.

Russ White takes the approach that the overall deployed system is very = complex containing many
dimensions of variability including but not limi= ted to time, topology, and local practice/policy.
Following from that is= a concern that, beyond a point, adding the additional complexity being pro= posed
results in either no benefit or negative impact to the goals of the global = routing system.

Hopefully I've characterized things reasonably a= nd this might help anyone who's having
trouble following at home.
Tony

On Thu, Nov 17, 2011 at 7:19 PM,= Geoff Huston <gih@ap= nic.net> wrote:

On 17/11/2011, at 5:10 PM, Randy Bush wrote:

>> The process SIDR has used is backwards --choose a solution, then b= uild
>> the requirements around that solution.
>
> the bgpsec requirements document was started from the 2008 document > draft-ietf-rpsec-bgpsecrec-10

That document never managed to reconcile the various views relating t= o
AS Path validation, so I'm unclear if you are citing this as a complete= d
activity, because to me it certainly appeared to be an incomplete piece
of work.

To be specific to quote from section 7 of this draft:

=A0 =A0 =A0AS_PATH Feasibility Check: The AS_PATH list may correspond to a=
=A0 =A0 =A0valid list of autonomous systems according to the first
=A0 =A0 =A0verification category listed in the "Areas to Secure"= Section
=A0 =A0 =A0above. =A0Further study will determine the extent to which this= is a
=A0 =A0 =A0security requirement.



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

--bcaec51b984f9c844a04b202df6e-- From robert@raszuk.net Fri Nov 18 06:32:00 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D01221F8B2A for ; Fri, 18 Nov 2011 06:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7PQFXwqiFrN for ; Fri, 18 Nov 2011 06:31:59 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 7343E21F8B15 for ; Fri, 18 Nov 2011 06:31:59 -0800 (PST) Received: (qmail 17984 invoked by uid 399); 18 Nov 2011 14:31:58 -0000 Received: from unknown (HELO ?10.0.1.3?) (203.69.99.16) by mail1310.opentransfer.com with ESMTP; 18 Nov 2011 14:31:58 -0000 X-Originating-IP: 203.69.99.16 Message-ID: <4EC66C5F.7040302@raszuk.net> Date: Fri, 18 Nov 2011 15:31:59 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Tony Tauber References: <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> <4EC4684B.3030204@riw.us> <855A62C6-6654-4FA8-8644-B7B044C76148@verisign.com> <4EC48834.9060805@riw.us> <09683D2C-A35A-4083-93D4-0E47B2106D83@apnic.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 14:32:00 -0000 Hello Tony, > Hopefully I've characterized things reasonably Sincere apologies for critics, but observing this space as well as hearing voices of operators from all over the world IMHO you have not even stated the basic preludium to the problem at stake. I think Russ is not just flaming that this is complex. The way I read what Russ is not afraid to say is that solutions in place are just not addressing the real BGP security issue. If they would we do know (with around for most of us 20 years of internet deployments behind our belts) how to educate community to deploy globally any new useful functionality. However the current proposal may very well address the Internet control issue rather then real internet security issue and this is the problem. This is something that non of the authors or implementors will ever admit is the objective here for a very obvious legal reasons. Best, R. > As that old draft's author/editor (started as editor, ended up more > as author, with suggestions), perhaps I can add some clarification to > some of what's being re-hashed here. It's likely many already > understand it; some don't; some could be aided by different wording. > > Steve Kent takes the approach that working through the processing > and propagation of updates and securing those operations to the > spec. The notion appears to me to be to model behavior based on > discrete events and the BGP FSM. > > Russ White takes the approach that the overall deployed system is > very complex containing many dimensions of variability including but > not limited to time, topology, and local practice/policy. Following > from that is a concern that, beyond a point, adding the additional > complexity being proposed results in either no benefit or negative > impact to the goals of the global routing system. > > Hopefully I've characterized things reasonably and this might help > anyone who's having trouble following at home. > > Tony > > On Thu, Nov 17, 2011 at 7:19 PM, Geoff Huston wrote: > >> >> On 17/11/2011, at 5:10 PM, Randy Bush wrote: >> >>>> The process SIDR has used is backwards --choose a solution, >>>> then build the requirements around that solution. >>> >>> the bgpsec requirements document was started from the 2008 >>> document draft-ietf-rpsec-bgpsecrec-10 >> >> That document never managed to reconcile the various views relating >> to AS Path validation, so I'm unclear if you are citing this as a >> completed activity, because to me it certainly appeared to be an >> incomplete piece of work. >> >> To be specific to quote from section 7 of this draft: >> >> AS_PATH Feasibility Check: The AS_PATH list may correspond to a >> valid list of autonomous systems according to the first >> verification category listed in the "Areas to Secure" Section >> above. Further study will determine the extent to which this is a >> security requirement. >> >> >> >> _______________________________________________ sidr mailing list >> sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr >> > > > > _______________________________________________ sidr mailing list > sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From ttauber@1-4-5.net Fri Nov 18 06:53:29 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634E921F8B1A for ; Fri, 18 Nov 2011 06:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXXvKZjIkKKo for ; Fri, 18 Nov 2011 06:53:28 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C1C1D21F8B13 for ; Fri, 18 Nov 2011 06:53:28 -0800 (PST) Received: by vbbfc26 with SMTP id fc26so255236vbb.31 for ; Fri, 18 Nov 2011 06:53:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.19.177 with SMTP id g17mr3916338vde.107.1321628008219; Fri, 18 Nov 2011 06:53:28 -0800 (PST) Received: by 10.220.183.74 with HTTP; Fri, 18 Nov 2011 06:53:28 -0800 (PST) X-Originating-IP: [24.104.152.66] In-Reply-To: <4EC66C5F.7040302@raszuk.net> References: <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> <4EC4684B.3030204@riw.us> <855A62C6-6654-4FA8-8644-B7B044C76148@verisign.com> <4EC48834.9060805@riw.us> <09683D2C-A35A-4083-93D4-0E47B2106D83@apnic.net> <4EC66C5F.7040302@raszuk.net> Date: Fri, 18 Nov 2011 09:53:28 -0500 Message-ID: From: Tony Tauber To: robert@raszuk.net Content-Type: multipart/alternative; boundary=20cf307c9bfaf4826404b2037fa9 Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 14:53:29 -0000 --20cf307c9bfaf4826404b2037fa9 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 18, 2011 at 9:31 AM, Robert Raszuk wrote: > > However the current proposal may very well address the Internet control > issue rather then real internet security issue and this is the problem. > This is something that non of the authors or implementors will ever admit > is the objective here for a very obvious legal reasons. > What are these? They are not "very obvious" to me. I believe people can get biased and entrenched based on their personal and professional stakes. I'm not sure what "legal" thing you refer to. Tony --20cf307c9bfaf4826404b2037fa9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Nov 18, 2011 at 9:31 AM, Robert Raszuk <robert@raszuk.net> wrote:
<= div class=3D"gmail_quote">

However the current proposal may very well address the Internet control iss= ue rather then real internet security issue and this is the problem. This i= s something that non of the authors or implementors will ever admit is the = objective here for a very obvious legal reasons.
=A0
What are these?=A0 They are not "very obvious= " to me.
I believe people can get biased and entrenched based on th= eir personal and professional stakes.
I'm not sure what "legal&= quot; thing you refer to.

Tony
--20cf307c9bfaf4826404b2037fa9-- From robert@raszuk.net Fri Nov 18 07:01:58 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9621F0C3E for ; Fri, 18 Nov 2011 07:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCnbBFh58uHa for ; Fri, 18 Nov 2011 07:01:54 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 85C9E1F0C34 for ; Fri, 18 Nov 2011 07:01:54 -0800 (PST) Received: (qmail 1960 invoked by uid 399); 18 Nov 2011 15:01:53 -0000 Received: from unknown (HELO ?10.0.1.3?) (203.69.99.16) by mail1310.opentransfer.com with ESMTP; 18 Nov 2011 15:01:53 -0000 X-Originating-IP: 203.69.99.16 Message-ID: <4EC67362.5050608@raszuk.net> Date: Fri, 18 Nov 2011 16:01:54 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Tony Tauber References: <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> <4EC4684B.3030204@riw.us> <855A62C6-6654-4FA8-8644-B7B044C76148@verisign.com> <4EC48834.9060805@riw.us> <09683D2C-A35A-4083-93D4-0E47B2106D83@apnic.net> <4EC66C5F.7040302@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 15:01:59 -0000 Hi Tony, > I'm not sure what "legal" thing you refer to. Oh apologies .. I was under impression that we all following IETF alias as well as participate in global NOG/RIPE events. As far as ietf alias see below: -------- Original Message -------- Subject: Lawsuit against IETF/SIDR/RPKI? (fwd) Date: Thu, 17 Nov 2011 12:06:48 -0500 (EST) From: Paul Wouters To: ietf@ietf.org Anyone have more info on this? Paul ---------- Forwarded message ---------- Date: Thu, 17 Nov 2011 10:34:54 From: Vesna Manojlovic To: p2p-sec@lists.puscii.nl Subject: Lawsuit against IETF/SIDR/RPKI? X-Spam-Flag: NO You've heard it here first ;-) But it's still only a rumor... (does any of you have more news about it?) Aparently, few big carriers in the States are preparing a lawasuit against RPKI creators, since they are funded by US government, _and_ are mandating the system that the ISPs will need to implement... so - anti-trust suit? Conflict of interests? etc... I could only find some "old news" about this: http://www.networkworld.com/news/2010/121510-feds-internet-routing-security.html That's why it is very important to continue with the development of the alternatives to the routing security... BTW, I got a ticket for 28c3, so -- see you there! Ciao, Vesna From ttauber@1-4-5.net Fri Nov 18 08:09:05 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB16421F8B15 for ; Fri, 18 Nov 2011 08:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1X9+uzGSR9Un for ; Fri, 18 Nov 2011 08:09:01 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 53B7221F8B16 for ; Fri, 18 Nov 2011 08:09:01 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so347828vcb.31 for ; Fri, 18 Nov 2011 08:09:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.91.162 with SMTP id cf2mr4213333vdb.124.1321632540683; Fri, 18 Nov 2011 08:09:00 -0800 (PST) Received: by 10.220.183.74 with HTTP; Fri, 18 Nov 2011 08:09:00 -0800 (PST) X-Originating-IP: [24.104.152.66] In-Reply-To: <4EC67362.5050608@raszuk.net> References: <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> <4EC4684B.3030204@riw.us> <855A62C6-6654-4FA8-8644-B7B044C76148@verisign.com> <4EC48834.9060805@riw.us> <09683D2C-A35A-4083-93D4-0E47B2106D83@apnic.net> <4EC66C5F.7040302@raszuk.net> <4EC67362.5050608@raszuk.net> Date: Fri, 18 Nov 2011 11:09:00 -0500 Message-ID: From: Tony Tauber To: robert@raszuk.net Content-Type: multipart/alternative; boundary=20cf3071cff81c6f3004b2048e28 Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 16:09:05 -0000 --20cf3071cff81c6f3004b2048e28 Content-Type: text/plain; charset=ISO-8859-1 Oh, an "obvious legal" rumor? I'm too busy doing work to follow all those. Has there been any follow up? Please copy all that nonsense here also so everyone can be involved in rumor-mongering. Or else, please don't. Tony On Fri, Nov 18, 2011 at 10:01 AM, Robert Raszuk wrote: > Hi Tony, > > > I'm not sure what "legal" thing you refer to. >> > > Oh apologies .. I was under impression that we all following IETF alias as > well as participate in global NOG/RIPE events. > > As far as ietf alias see below: > > -------- Original Message -------- > Subject: Lawsuit against IETF/SIDR/RPKI? (fwd) > Date: Thu, 17 Nov 2011 12:06:48 -0500 (EST) > From: Paul Wouters > To: ietf@ietf.org > > Anyone have more info on this? > > Paul > > ---------- Forwarded message ---------- > Date: Thu, 17 Nov 2011 10:34:54 > From: Vesna Manojlovic > To: p2p-sec@lists.puscii.nl > Subject: Lawsuit against IETF/SIDR/RPKI? > X-Spam-Flag: NO > > You've heard it here first ;-) > > But it's still only a rumor... > > (does any of you have more news about it?) > > Aparently, few big carriers in the States are preparing a lawasuit against > RPKI creators, since they are funded by US government, _and_ are mandating > the system that the ISPs will need to implement... so - anti-trust suit? > > Conflict of interests? etc... > > I could only find some "old news" about this: > http://www.networkworld.com/**news/2010/121510-feds-** > internet-routing-security.html > > That's why it is very important to continue with the development of the > alternatives to the routing security... > > BTW, I got a ticket for 28c3, so -- see you there! > > Ciao, > Vesna > > --20cf3071cff81c6f3004b2048e28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Oh, an "obvious legal" rumor?=A0 I'm too busy doing work to f= ollow all those.
Has there been any follow up?=A0
Please copy all th= at nonsense here also so everyone can be involved in rumor-mongering.
Or else, please don't.

Tony

On= Fri, Nov 18, 2011 at 10:01 AM, Robert Raszuk <robert@raszuk.net> wrote:
Hi Tony,


I'm not sure what "legal" thing you refer to.

Oh apologies .. I was under impression that we all following IETF alias as = well as participate in global NOG/RIPE events.

As far as ietf alias see below:

-------- Original Message --------
Subject: Lawsuit against IETF/SIDR/RPKI? (fwd)
Date: Thu, 17 Nov 2011 12:06:48 -0500 (EST)
From: Paul Wouters <paul@xelerance.com>
To: ietf@ietf.org
Anyone have more info on this?

Paul

---------- Forwarded message ----------
Date: Thu, 17 Nov 2011 10:34:54
From: Vesna Manojlovic <becha@xs4all.nl>
To: p2p-sec@li= sts.puscii.nl
Subject: Lawsuit against IETF/SIDR/RPKI?
X-Spam-Flag: NO

You've heard it here first ;-)

But it's still only a rumor...

(does any of you have more news about it?)

Aparently, few big carriers in the States are preparing a lawasuit against = RPKI creators, since they are funded by US government, _and_ are mandating = the system that the ISPs will need to implement... so - anti-trust suit?
Conflict of interests? etc...

I could only find some "old news" about this:
http://www.networkworld.com/news= /2010/121510-feds-internet-routing-security.html

That's why it is very important to continue with the development of the=
alternatives to the routing security...

BTW, I got a ticket for 28c3, so -- see you there!

Ciao,
Vesna


--20cf3071cff81c6f3004b2048e28-- From kent@bbn.com Fri Nov 18 22:03:06 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6432621F8A97 for ; Fri, 18 Nov 2011 22:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.54 X-Spam-Level: X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brOoWee4fJfQ for ; Fri, 18 Nov 2011 22:03:05 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE7E21F86A4 for ; Fri, 18 Nov 2011 22:03:05 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:33235 helo=[10.59.75.27]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RRe10-000CjJ-TZ; Sat, 19 Nov 2011 01:03:03 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4EC67362.5050608@raszuk.net> References: <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se > <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se > <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> <4EC4684B.3030204@riw.us> <855A62C6-6654-4FA8-8644-B7B044C76148@verisign.com> <4EC48834.9060805@riw.us> <09683D2C-A35A-4083-93D4-0E47B2106D83@apnic.net> <4EC66C5F.7040302@raszuk.net> <4EC67362.5050608@raszuk.net> Date: Fri, 18 Nov 2011 23:41:37 -0500 To: robert@raszuk.net From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 06:03:06 -0000 At 4:01 PM +0100 11/18/11, Robert Raszuk wrote: >Hi Tony, > >>I'm not sure what "legal" thing you refer to. > >Oh apologies .. I was under impression that we all following IETF >alias as well as participate in global NOG/RIPE events. The message in question reports a rumor, with no substantiation, so ... Steve From christopher.morrow@gmail.com Sat Nov 19 22:56:31 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08E121F854D for ; Sat, 19 Nov 2011 22:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.555 X-Spam-Level: X-Spam-Status: No, score=-103.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9E0uQd0c2M6Y for ; Sat, 19 Nov 2011 22:56:31 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 618C321F84FA for ; Sat, 19 Nov 2011 22:56:31 -0800 (PST) Received: by iaeo4 with SMTP id o4so7009336iae.31 for ; Sat, 19 Nov 2011 22:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eaP/Mlg+kIl6q0E6wk5SJsHR6WbLv5tP1XQ+jiOIdVU=; b=pxHAgp18lycjsWrrQC+QmpJlKxyOm9NTfLM42TqCJsFgEcQZ6BVuHBnWuAv12mIPjN X+eO9uYB/KYIAKPt2PeXG0yhHkPTFQY0UW/yVTBZtuZ48jAogekg3A0j0rZcF7vzfpou DBlJf1epc2BD2/fFruGcY8ac9CpNUehYGiocU= MIME-Version: 1.0 Received: by 10.231.41.4 with SMTP id m4mr2146658ibe.44.1321772191009; Sat, 19 Nov 2011 22:56:31 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Sat, 19 Nov 2011 22:56:30 -0800 (PST) In-Reply-To: <4EC60A7D.3030306@ieca.com> References: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> <3F1388E3-A694-42C9-AE2F-F12BF15DC86F@verisign.com> <4EC60A7D.3030306@ieca.com> Date: Sun, 20 Nov 2011 01:56:30 -0500 X-Google-Sender-Auth: SaUJfAqr_t07YiNsok3rdgTwoNM Message-ID: From: Christopher Morrow To: Sean Turner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org list" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 06:56:32 -0000 On Fri, Nov 18, 2011 at 2:34 AM, Sean Turner wrote: > On 11/18/11 2:21 PM, Christopher Morrow wrote: >> >> On Thu, Nov 17, 2011 at 12:50 PM, Brian Dickson >> =A0wrote: >> >>> Here's the thing - if all-A chains continue to exist until Phase 4, >>> _and_ fallback to Suite A is required, this is a downgrade-attack >>> vulnerability. >>> >> >> It seems to me that as long as there are consumers of cert material >> that can not do the 'new hotness' (B in your example) you will have to >> make products in the 'old and busted' form. Once everyone can do 'new >> hotness', there is a relatively short period of time required to kill >> off 'old and busted'. >> >> I don't think you can get away with not making 'old and busted' until >> everyone is able to plan ball, eh? > > Hope of hopes here is that we don't just transition when an alg is broke. > =A0Algs weaken over time - that's just a fact. =A0When we retire an alg b= ecause > it doesn't cut it anymore, then running with the old unbroken alg is a > downgrade but assuming the alg ain't broke then it's probably okay for th= e > transition period. do I have to apologize for the MIB refernce? From randy@psg.com Sun Nov 20 01:54:51 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3036321F8515 for ; Sun, 20 Nov 2011 01:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoSKvEXpd4PH for ; Sun, 20 Nov 2011 01:54:50 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4A821F850E for ; Sun, 20 Nov 2011 01:54:50 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RS46m-0000Vt-T4; Sun, 20 Nov 2011 09:54:47 +0000 Date: Sun, 20 Nov 2011 10:54:42 +0100 Message-ID: From: Randy Bush To: Stephen Kent In-Reply-To: References: <4EC32EBE.6030106@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20633@EUSAACMS0701.eamcs.ericsson.se> <4EC33E88.9090505@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A20649@EUSAACMS0701.eamcs.ericsson.se> <4EC459F0.9070200@riw.us> <4EC462E9.7090103@riw.us> <4EC4684B.3030204@riw.us> <855A62C6-6654-4FA8-8644-B7B044C76148@verisign.com> <4EC48834.9060805@riw.us> <09683D2C-A35A-4083-93D4-0E47B2106D83@apnic.net> <4EC66C5F.7040302@raszuk.net> <4EC67362.5050608@raszuk.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Sun_Nov_20_10:54:42_2011-1" Cc: sidr wg list Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 09:54:51 -0000 --Multipart_Sun_Nov_20_10:54:42_2011-1 Content-Type: text/plain; charset=US-ASCII > The message in question reports a rumor, with no substantiation, so ... --Multipart_Sun_Nov_20_10:54:42_2011-1 Content-Type: image/jpeg Content-Disposition: inline; filename="dont-argue.jpg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEASABIAAD/4gVASUNDX1BST0ZJTEUAAQEAAAUwYXBwbAIgAABtbnRyUkdC IFhZWiAH2QACABkACwAaAAthY3NwQVBQTAAAAABhcHBsAAAAAAAAAAAAAAAAAAAAAAAA9tYAAQAA AADTLWFwcGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtk c2NtAAABCAAAAvJkZXNjAAAD/AAAAG9nWFlaAAAEbAAAABR3dHB0AAAEgAAAABRyWFlaAAAElAAA ABRiWFlaAAAEqAAAABRyVFJDAAAEvAAAAA5jcHJ0AAAEzAAAADhjaGFkAAAFBAAAACxnVFJDAAAE vAAAAA5iVFJDAAAEvAAAAA5tbHVjAAAAAAAAABEAAAAMZW5VUwAAACYAAAJ+ZXNFUwAAACYAAAGC ZGFESwAAAC4AAAHqZGVERQAAACwAAAGoZmlGSQAAACgAAADcZnJGVQAAACgAAAEqaXRJVAAAACgA AAJWbmxOTAAAACgAAAIYbmJOTwAAACYAAAEEcHRCUgAAACYAAAGCc3ZTRQAAACYAAAEEamFKUAAA ABoAAAFSa29LUgAAABYAAAJAemhUVwAAABYAAAFsemhDTgAAABYAAAHUcnVSVQAAACIAAAKkcGxQ TAAAACwAAALGAFkAbABlAGkAbgBlAG4AIABSAEcAQgAtAHAAcgBvAGYAaQBpAGwAaQBHAGUAbgBl AHIAaQBzAGsAIABSAEcAQgAtAHAAcgBvAGYAaQBsAFAAcgBvAGYAaQBsACAARwDpAG4A6QByAGkA cQB1AGUAIABSAFYAQk4AgiwAIABSAEcAQgAgMNcw7TDVMKEwpDDrkBp1KAAgAFIARwBCACCCcl9p Y8+P8ABQAGUAcgBmAGkAbAAgAFIARwBCACAARwBlAG4A6QByAGkAYwBvAEEAbABsAGcAZQBtAGUA aQBuAGUAcwAgAFIARwBCAC0AUAByAG8AZgBpAGxmbpAaACAAUgBHAEIAIGPPj/Blh072AEcAZQBu AGUAcgBlAGwAIABSAEcAQgAtAGIAZQBzAGsAcgBpAHYAZQBsAHMAZQBBAGwAZwBlAG0AZQBlAG4A IABSAEcAQgAtAHAAcgBvAGYAaQBlAGzHfLwYACAAUgBHAEIAINUEuFzTDMd8AFAAcgBvAGYAaQBs AG8AIABSAEcAQgAgAEcAZQBuAGUAcgBpAGMAbwBHAGUAbgBlAHIAaQBjACAAUgBHAEIAIABQAHIA bwBmAGkAbABlBB4EMQRJBDgEOQAgBD8EQAQ+BEQEOAQ7BEwAIABSAEcAQgBVAG4AaQB3AGUAcgBz AGEAbABuAHkAIABwAHIAbwBmAGkAbAAgAFIARwBCAABkZXNjAAAAAAAAABRHZW5lcmljIFJHQiBQ cm9maWxlAAAAAAAAAAAAAAAUR2VuZXJpYyBSR0IgUHJvZmlsZQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAFp1AACscwAAFzRYWVogAAAA AAAA81IAAQAAAAEWz1hZWiAAAAAAAAB0TQAAPe4AAAPQWFlaIAAAAAAAACgaAAAVnwAAuDZjdXJ2 AAAAAAAAAAEBzQAAdGV4dAAAAABDb3B5cmlnaHQgMjAwNyBBcHBsZSBJbmMuLCBhbGwgcmlnaHRz IHJlc2VydmVkLgBzZjMyAAAAAAABDEIAAAXe///zJgAAB5IAAP2R///7ov///aMAAAPcAADAbP/h AOJFeGlmAABNTQAqAAAACAAIAQYAAwAAAAEAAgAAARIAAwAAAAEAAQAAARoABQAAAAEAAABuARsA BQAAAAEAAAB2ASgAAwAAAAEAAgAAATEAAgAAAB4AAAB+ATIAAgAAABQAAACch2kABAAAAAEAAACw AAAAAAAAAEgAAAABAAAASAAAAAFBZG9iZSBQaG90b3Nob3AgQ1M0IE1hY2ludG9zaAAyMDExOjA2 OjExIDIzOjIzOjU0AAADoAEAAwAAAAH//wAAoAIABAAAAAEAAAGQoAMABAAAAAEAAAGRAAAAAP/b AEMAAgICAgIBAgICAgICAgMDBgQDAwMDBwUFBAYIBwgICAcICAkKDQsJCQwKCAgLDwsMDQ4ODg4J CxARDw4RDQ4ODv/bAEMBAgICAwMDBgQEBg4JCAkODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O Dg4ODg4ODg4ODg4ODg4ODg4ODg4ODv/AABEIAZEBkAMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAA AAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEU MoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2Rl ZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK 0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUG BwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS 8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4 eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri 4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/APsn42/tGa94D+PvhX4PfDD4cz/Ev4q61a/2 hHp9xe/YLKCxBIed7ghgMEY2gE8j1rDX4n/trG7AH7Mnw7Cldyt/wsn5Vzn5Sfs2cjjoMVYittP8 Uf8ABcnU5bi38y58D/CqAWkuAAJdQu5N5bIySqWyBSD/ABtX2AVHlKOGxjaSOa/iHGVsFgqdCmsL GcnBSk5Od7y105ZxVrW6X1d2fpUFVqyk+eyvbS36pvc+Rj49/bTFobg/s9fCRnHIt1+I0vmHGOMm 028jpz2qeX4j/tg3VssOn/s3/D2wvd2Xn1H4iB7bb2xstyxb1yAPevq/qm3gc/nTgMnIwR6V5qzb Cv8A5g6f/lX/AOWG/wBXqW/iP7o/5HySkP7c2tXVsz337N/gOMqfPQQX+rMCTxzmEcAfjntjm9/w h37Z6KJE+PHwVlkLcRSfDq5VFHcAi9zwe1fVe7joM47+tSFwVBIA9aHnbXwUKaXbkT/9K5n+JLwz e8n+X5WPlKLTv21bTUZY5PFn7OuuW4TKTtol/ZsSV+6UEz45755HatKLTP2w9RtpY5fGPwC8NyeW BG0OgX1+VbPzHBmj4PYH9a+lwf3mSHz12jpSkMOdpj4zyaTzbW6oQT/w/pt+A/YP+d/h/kfLll8L P2k9RaVfFX7UA09MKyL4S8E2tqVOSWG65abjGAOM4z35pT+zz4/n2yXf7WHx9e5QsVlgXSohyABl Ba7SRz25zz0FfT6jDPnbjqM0/KjlCCp45GTWjz7E8zcYQ/8ABdP/AOQE8LG27+9/5nzVp3wR+KWk Xhu7H9qr4uahOeDHrek6VdQsO3yJboR7881P/wAIV+1DZa0FsPjv8O9W0cIQg1n4fP8AaicdS8N0 qH5u2wce/NfRp4LYYn/apTnodobHTFR/bVabbnCD/wC4dP8ASKH9Wilo397f53PnKGz/AGtI4gJ9 c/Z+uZBIQHGmahGGXb1x5h53ds9DUkb/ALWbR4aH9nuF2mwSs2oSbY/XoMnNfRRfDZwM44ApP4cg Luxk5ArN5mv+fMPua/VFezn/ADfl/kfP8eh/tQyWMa3XxH+DVtM8hMssPgy6k8tTnChWugGIOBuJ GR2qA+Dv2mEaIr8c/AjBLZhtf4eHDydmP+lZ2g9hzjvX0Lzu+Y4+XgbqUDlQMnA/Cms4q7qnD/wC L/NMTw93dtnzK3hb9ry3M5j+MXwQ1T7vlC68A3cOw4+Y5S8OSemOMe9SW1r+19aXlutzq37Pms26 xoZpBY39qZXLYYKN77AFwc5bJ9K+lwMPnOB2BOM0vONpyDnIpvOJP4qMP/AUvysP2LW0n+H+R83p rX7W8PijypPA/wAA7nSFHzXUfiy/SR/YR/ZSBnpy1VYPFH7Xzagiz/Cb4ErArESbPH125bIOGANk vAOMjPrX01gsjZY8GmYVioDbSDyfQ0LMsO3rhaf31P8A5YT7CX87+5f5Hgovv2pprqDd4b+BVqjT r5g/tu+nMaH7xA8lckdhxn2rNv4v2ub2e3js9R/Z/wBARkczSSW9/elGEg2qE3R53Jkk5G0nGGr6 LJdcFcnPpjn6mlJyMgA4HzfWlDMoRkrUIaeUn+cmNUZ/zv7l/keBweFv2krjVll1D4xfDuytghBg sPA0jZPUENJcZBB65zn2rNuvA/7UBKGx/aA8ClShVxd/DncCezDZdLgg/XgfjX0iMHLbxuA49zUe CvCtnvyaSzeopX5If+AQ/WInhk/tP7z5/ufCn7TMWqW1xYfGb4aXcOCLiC+8BSgscDG147oYG4HO QeD680/7L+1RHpsQGu/AS6vBKpdm0rUIoymDkY8wnI7c8+1fQBztJQc+nUihseXuOCe5Apf2k5JK VODt/dS/9Jt/Ww3Q6czPBotJ/acuIphcePPgvpj+RiI2vhW8uMyju2+4XC47Dn3qG28J/tLyQx/2 r8avhvbEtmT+zfh6+FXb91TLdNnnnJr30liWOFOO+ScU9du4kquSMkFqf9pOKaVOH/gEX+aYpUL7 tngUHw++Os2pXLar+0P5dl5m63i0vwVaxOo9GaRnBH0ApJfht8ao9PMdp+0fqxmJYrNeeDbGRhnk D5dvA9K9+JywGdoPULz+FLkNtwwHHSiOa1NPch/4Lp//ACI/YLu/vZ87DwJ+0dbXKyW3x/8ADF6C Asqaj4AUgDuU8udSPoc1A+g/tVw32vyQ/Ej4M39uGQ6LbT+D7qF5QB8wmkFyQh7Aqp9cdq+kEAYs fl59+tMyVZgSePTtS/tZu7dOH/gEF+UUHsLv4mfOp039rSXTZ8eM/gFZXJKmPf4cvpkjBX5gcTqW IPGeMjnimnwt+1RJe27z/GD4O6eokUzw2ngC5kVVyd2x2vPvEYwSDg54NfRZYlAysCcHqOtO3FwQ 48v6Ch5s0vdpQ/8AAIv80x+yf835f5Hz9eeAv2gL23tw37Qekac6xfvWs/AkHL7uCpeVsDGQQc84 6VYb4Y/FaSe2eX9o/wAZhRFidIvDumoJGySGH7s4xx9cV7v1k2Egj9PrSZAA+63HzYFZ/wBr1Xb3 I/8Agun/APIjVBWtd/ez57Pwz+OVkZ5dK/aT1C8uZGVlXWfBllNCoHUYi8tsY6fNSweE/wBpeB1V vjX8OLuAM2Hn+H0m8gkED5boDgcZxzX0GMsCzLjjjNKCfm3L26etH9qz/kh/4Lh/8iDoJ9X954pp OmftG288K6z4u+DV9BuAkmtPDt7C7D1CmdgD7ZpqWP7RsWtyI3if4L3mmfaSVkfRr2OdYuw2iUqX /ECvbyQcgFieDyOKCJVIIAYdCPSpWPc270o6/wB3/L/hg9m/5vy/yPGF/wCGhS0zNd/BoqWIiVYb 9cJ6kk9c9q5y61f9q23uZFtPBfwH1VUI8st4nvrbzhyOf9GfYeh79favopNxBUtnjv2pFb5B6Anj 1pxx9OP/ADDwkttedflJfmKVKT0U3+H+R81nxN+1v9hbZ8I/gm0+zqfiDdbCePSyzgc+/HvVUeLP 2vBZhv8AhTfwRlkCkMi/EW6GWzwRmx+7jnnmvp5Sd2DgDkgE9qCdx2hdzH35x61p/alBafVKf31P /lg3Snf4n+H+R8u3fxO/ad0aWc6p+zbpHiC0ECug8MeOIZpS/O5MXEcIJ4GMHnPamj48fF1LGCa5 /ZE+MwuPJ3+Xb6to8mw7tu05uwQe/TpX1Ftyqk5Az8oA5pGwHyWIB64Peq+v4R25sHD5Op/8mxOl Ub0n+CPlC5/aC+NCw4sv2PPjLM2c5m1jSEIH4XR5z2rNu/2o/H+i2iNr/wCyN+0FaSkOVNlbWF6p dei5iuGIz6kAV9gqMq33ShGSSxyKUE7WBLL3f5iKazDAN64NfKdRP8ZP8ifZVf5/wR8IX37Sn7Uu o6RY3vgv9izxlLbS3IM39ua/Z2bmAjgqvmFhJnHDDHvXa/s0/tJeJPjH8YPil4E8e+Bo/APjbwde Qxz6VHeJcqiNGpbdIvBkDMQQMjA6819eZwAQ+8MB6Eivin9m6x0Zv+CgH7YurvPM3i6XxpaW13Gt p5cUVmljAYCD0LMS2cdeMjoa9qjXy7GYDFWwkYShFNSi5t3c4rXmk1azfRdDnmq0Kkbzun5JdGdL 4HuBff8ABYv9oC6jg8yCy8C+HdPluBE20SiW9lZC/TftkjJHoVr6vYgjGSDnPFfLng29j0v/AIK3 /HHw/JGqf2z4L0HWrYIX2SBHureTI6bwUTJ7gqO1fUZzuYg59OOledn7TxMNLfu6f/puP63OjCJK L9X+bBVTaAAQR196d0w64A9j1pFA2AkEkjjbS7js5wSo7V4CV2dQ3AD8nv09Kc3cAnPUYFJhiBn5 cjuMinkEMcKp9MHt9KbYrgGiVQ7KST17GkxhxvKkYyQoOMUvJKqHAbBwCM7qQH5l5PuRWdk3p+RI 0KruRHgHqKQgogb5QmeR608AHI6qOuePyxTd2AcHK9gR0qml2KHD5UABf1zRnk8cNxgHvTiDlTs+ YjjtTCp2AAZOcZAxUJx6i3ADk71CnuV5zSlsY+TjHUCgBvvlenBAPelBGAp3Bep//VWluoNjDgSZ KY98U4vwNoBXHTuPanZVslQxGM9evvTWPOXB39elJxtZgmKVDHlQGI6ZpgGV5PPfmnbfm/eFuD/E ablvNIJO0cgA0NsYvOWUA8juSPypMhWyM553UrZ3FQTnPUnIP0pmOeNpc9BnrWfOtwQ8hdmSB26H FP2gHjg9j6+1Qkggnke39aXKgDJJJ6kjtVKfkHKx/AfbnjHrzTGUjLHaoPbHSgH5eDkk/h/+ukJZ mBLBBzn1qlUVx2DKht248dx1FOBbClSevNI2Qm4sSRwQaaXP64xnkUvaK2jCwpJBOTk564p6kk/f IGOQQKYNzD5jx1Ix6U4/KUJIY56jrT5kBJjGF8wcHpxj86aVbfyucZByOlISDjgHOcUvPzKwKj69 aHNWuyRAq7iCAT056fnTTgg7SeR6YzTyOg4J9z2ph7qBtwfwNJzfQa3G7t2Vbd9COKfyUKqcA4ye uaYihgBnLAcA8U/ZgsSQQc7QPaplOLHsCHEJTaqr1zjHT3poAzhThc9GbH50qrkbhgkH5u/50ruM 5ZkX3xyf8KcWr6gDKwDDLA/XvQ3mbMnjA4FGS/T19aT5SFIYjHbPFP3bJCFIbaAOp4xjilKnzchy vpg8dOeKAMyAeYq5OdoGc04sq7QVJJyPm45ofK/UTYgzuPzFmC8cAGmlTlQDGo9D1zSkkqegYA8d KUMTk42kjLdMColGzbX9feCGL8rchfxNObPzEgMc/wANM7FupB7ihSwj6RkHquOtQ3GLuWx7DGEZ yOwKnOKYRgH5sqBwM00/eA6jtmnDJzn5WzyTx+VWppLUQjli5QbS/wB7pxTlVjy/LEgjFR8FmAJM g5YlcfrSq6FXEmBlvvAkUoyT6DexKoU7ww6jr618q/CH7Tpv/BTP9qPRvswg0y6bRNYjkRFImmlt mhcsc53BYE+XAwMHnNfVQXeSv3ic455r5U8EeFtTtf8Agr/8bvFLz2MWmT+B9DtfIjiPmTSebdMJ JSeNwGQCDyO3HP0OUyh7DFpu16a/CpTOPEfFD1/Rml4Pxd/8FY/jjPJotyr2HgrQLSHVGLtG297u R4FJG1cZViq8ncCe1fTGMkc7ecY7V85/D+/tZv8Ago9+0TpMdrdLNDp+gzS3EkzkSb7eVcKpOwAb eoG4knJxivov5wNjIvy9CO9Rn8nHFRVrWhT/APTcfUMIrQfq/wA2OXGCxy7KDwRjNCFS2MBfQg0x W+TlC2RwDyakBGz5SGIFePGpFvU6WgCgqMMCTzjNOC7VLcZOOQelR5JIIyAeTmpB9wDIVsnBNa8i YMQKZAckkDkYOCDTwPl9iOwzUZVSfm9eN386eRhWAYZPGOoNEqSRLZGQwU7wT3yOcilxtGRuHqCe aey/Nt3gc5XHWlKkjpuYDAHY1Eou241IacCUcYO3IGaaMlcsZDk8f14pxy0mQi4P3gcimqjMoAT6 HdnNZqLtuO/cr/vPtRUorLjIYtU5+aLhQGHcd6RsmRSFdT6AcUBCSUznjOAahcyeg73G5IGQuTt5 5waU5V85bHc9cU3Bycg5brn0p2CCeGIz25Bq25JbFaAWUqpJztOQWXNAJG0E5LckAdRTWA27lTr0 y1LgnYSp9ATUNCFAXABHyk5YkdKbkhgSWXHA4zgVzfjDxn4X8A+Ar7xN4z8QaT4a8P2ib7i91C4E UYAHTJPJ9hXy7afti6T4zkWL4H/CT4t/GdiGze6fpP8AZunqB90/arwxIwbtsLcDNduCynF4yMp0 aTlFaOW0V6ydkvmzKpXp0/idj7GIwytuOMYBPahQ5CtjhjyPX3r418QeJP26dZtnPgz4T/BTwQHG I5Ne8XzX00YPd0jhC5HQgMRx1qCy8Cft4C0W6vfjb8EUuXj3PaHwbcSRRsTyqsJwSB613/6uT5Oe delHyc+Z/wDkilb52M3i4J2Sb+T/AFt+Fz7SC7pGBkbaB9PwoKjdu5wB3PNfFTz/ALe3hO/tr250 j4D/ABZ0uIyG7stLmuNIvJRxsMZl3pnrwSOcfWvQvhh+0r4U8beP5fAHjHQvEPwj+K9um6Xwt4qV YZrhe72soJjuUz3jY44yAeKzq8P4qnTdWDjUit3CSlZd2l7yXm0kVDE05NK+vZpr8/0PpPg5LYPH LZ4FMKkZwASPbk1OVQqEHOB93GCaayqUDAtkcfe4rx/ZvdmykJhdykDcQcnPU0qthwMFQO+P60FB HJuIw3ufWhc9t69SWzkUlTC4co4dexOSTmngsFONrAN3GcGhlLMpYDGMj3pgVV6ZGf6+lVGAtx3f 7p68Drig5zkLnI656UBFUKGVwOxB60pyvRycHvW6hcLhlGIYKMAHqMU0gl1IwBjHH8/rQy4kwWBG Og70rFc4weucGsnDsMCEK4+ZTngjuKYX5OwZZfwzShcgsMqGJOc9D9KQD5zlQMDuaSjrcEKQCgHO fQGkAIDMwIGcg5p5K8jOenTqKdtycnjJ6Dt/hQriuMywGc5brzxmnKxCZdRnrgc8U1+hZgV54z/h S8/3WYY/vAA+1Uou2gdBQ2MHj5jyD2pj4yTuAI6D19qXKo5IVxwOcA49qQODKQA/POfemmt/6/IY 0plA+QcdMgg0MMupVF6ccnIqTcWlDFtpPHIPFPIAVT8u4nr/ADrNrbXUOZkY+Uk8hezBeh701QuS u8Nn1bqaeW53AgcYz1zTXOAoCKD7HOaSpp6NgmOJAA5U7TxuJxn/ABpmzK5wpB+8T2P+FKsi8DcQ wbOMce9BBCNzlWPAbpimoLYWwhKPhgm1uTuz1r568M3Udn/wVQ+J2m/b5JLjVPAWj3os33kIIp7u MuvG3B3AcHIx05r6H2pt4UDjpjrXyhcaLZWn/Ba/Qdd0z+04L7UPhPdJrHluDbTJDexC33A8qwMs uCOuTnoK9vJoRksRCT3pu3ycZa9tvvOfE391rv8AodJ4Gv5j/wAFJv2gNMecALougTRxvEFKK0U6 5VupUlT+INfRT4IUFcngnPQ4r5y8GW9t/wAPQ/jlfeXcR3jeEPDsbNvzG6B70qQvqCWBzz0r6PzG X2hxkdjnrSzeEfrEGv5Kf/puI6Gz9X+YpUnn7pAxwaiZQA43vz0APIqwFHlsSq5U96QKWbIIBYcc CvIVJs2UrFfIAOSGycYqXLYGQ3sB3pPlGMsGIOCCP50u3djAyATkHoR61aTTG2AwPvEgg85pwwE4 Acd6PmIPTg+3FNLdgFCjoQK0a7oRKCpbK8N0OOc/WjALjMgA5+h9zUPIPyvx6ntUjFGGSE4xzkiq TT0FYcQAQxbjHY9aaQFXJO7joD39aAeD1xnjJFO4YgZVR9e/bmh04yQr2GbdkeFL89Rij+D+EHHX GaUFty8nnrzSZ4U4wPQcVnKnHsO5GrAj7p+919f/AK1TD5vlYHPUnHb2phjbduJ3bh29KdjEbHfg dcEVm6SQ20Qt/rDhCFzkAjmvnr4y/HJvAvjjw78NvA+hS+O/jH4ngll0LQgWS2t44/v3d5MoPk26 kjkjLHgZr33Ub6z0rSLnUNRuo7WytYDLc3ErYSJFG5mJPYCviv8AZF02T4g+M/it+1BryPNqnjbW 5tN8Lv5bAW+g2chjtxGG6LKwaXI4YMOSMV7eV4ClyVMTXjeFO2m3NKXwxuum8nbW0Wrq6ZjWqyTj GO7/AAXV/wBdzq/C37LljrXxAtfiJ+0J4ik+M/xAQpLaWV1EYvD+iSKcgWVlkruU9JpNzn15xX1t GIooVhhjWOFF2iNFAVR6AdMVgeKfEOk+Dvhxr/izXZpLfSdHsZL28aKFpGEUalmIUck4HQVQ8BeO fDfxJ+D3h7x54RvpNR8Na1Zpd6fcPG0TSRt6owypB4IIyKyxeIxWLhGpVu4R91WVox68qSXKvRav fzFTpU4Oy3/E6zkMOFK9toqUtkMOQMdRxTNw3L8g5J7cVBfSXKaNdPZQxT3ywubeKV9iO4U7VJHQ E4Ge1cahFGrLGcsB8zDPAY15l8U/g/4B+Mnw4Phvx5oEWowxyefpmoRP5V7pc4B23FtMPnikXJIK mui8CXvi/UvhRol94+0bSvDXi+a336npmm3xu4Ld8nCLKVXdxjPHWusABXIHOODXRTqVcNWUoStK L3T6rs07fdoROMZxs1dM+Mvhf418ffCT9qHSP2b/AIu6y3jO21bS5b74fePLgpDNqkUJAksbqPP/ AB9RqVO9eJF5wMEV9mYTCnazDI6DtXx/+2zpk1t+yBB8U9HtvP8AFHw116y8UafcKcSwwwzKt4oJ 6hrdpRtPUkegI+stL1GHWPCul6tbtuhvbWK5hbIxtkUMP5135pSp1qNLFwSTm5RklouaNm2ktEmp RdlZX5rK2hnRnJScJPb8n/wzLDJIzZDOFzjk1NtCNknaVPygc0pZd5XKv7jv70fIf4NpzncDmvDc E3Y6bjS3yEkgN6leRTV2+URlFye4z+vpTm5P3hnPY/p7U3Zy5BY8dAaXIlEEKA2QC5JH4ZoJUgjZ jjqe9BXJwCFOPl5AzTcHdktgY6E1KUUtAAD7pXIYnigjLdHDYzhqcpAUjKFsdhzSAFQNx7dxTaQ0 ISqooJ/ClbGQFAU9x70NG+0OQvIz83NPC5BJwQOm1v8AOaTjcG0RD72eh7nbzT23DY2GHcFjnFID lwC2VAx0yRQpCx9cqeASAOKh02tQuNzlTuwOeQaQgd9uegAzzUoxjj5fXK80ZXf84BX6d6nmaYXG hswZLY74/wAc0rFAM5ZiTwW6U0MM9Pl9zTiqksdoKk8ZHSq97uAH5uQRjqTn9KZkLyyk4bI4zgUu xT0O0gce1JjIyysXz1UenelZ9QVhpcjOScZ4O38qUcKVZS57kDrTiCYt2WL55z1pSxDk+YmB/d6C r6WQ7jSc7WQKG5wCMjFJkgqjlWK9QwPSgGLGeGHuSKXBaQKVVQOp96Sv1AcBkADDd85r52nNsn/B UrRFlvpo7lvhncpaweWSJf8ATozIwbplfkyP9oe9fRTqQAQAxBzndjjv0r5n8RwXMH/BW/4R3Imd bS4+HWuWvlALtkcXVk4OTzwN3Fexk9NSnVX9yf4Rb/QwrPReqL3w+Uyf8FC/2iriS9WWVLHQLVYF QfuUWCZwc5ySS57Y6d819EBlEbAHknOcV85fCuRrn9uv9p+do1QQ6po1srOmGYLpyMcf7OX/ADzX 0c20kZCkckEDilnT5cSl15Kf/puIsNblfq/zYuG2AgkjHtiml93GOQOx5pwAVCQRjHakwQVChicD kV46m0bibTu4AJYZyOpoDKTjaQQPXH60ofPzZHpjNK24gfMuM9NtDlcCIhcHC8jkZ5FKH+Xnr6AU 88HoVHt1pOvBXK45IbFTz+Y7jSTs7Bc5NKpAbkk46EjmkbJcg9xwCMU0GTBAQ8jIYcgVXPK1kNLQ nBPUP0GQN1NDAKSzYcevSmgENk4BwcYbn60Esy9NyA/dPfjvUe1FYN5wdpXcRjAGBShyW5ZQB6nr 7UxRtUg4ZsZwKcuPmwqn8Oc1o61waFZiD3B/h55pA/oznKkc+9I4BVgAyng4J4/+saGYCMFfnIH+ TUKaC2h8oftnfEO48FfsX3+haLctaeK/HWoW/hPQpsf6me8YRmQjByEUs3TnGK+gPhr4Psvhz+z/ AOCPAWnqBYeHtEtdNiPJz5USqTySeSO9fH37Z999j+L37Isl2jnTR8WYXkWNSzFxbTBOACf4j0r7 xkdHlYq4+9k47nPvX0eOm6OT4WMVpUc5PzafKvuSf/gTOOmnLETb6WX6/wBegSiOa2milRJYnUrJ G+GV17gg9vaq9rb2tlZw2djBBZ2kKhYbeCMRpGPQKAAPwFShMscld4PBB5I9q8g+OXwvuPjD8B7r wlZ+M/E/gPWVuY7vSdb0W6MM1vcR8x7sffjPRkPUE968PDVqc6sadWfLFtXdm7edlvbyOmSsm0rs 9iLZc5xkHGCa4D4o/E3wn8Ivgnr/AI+8a6pHpOg6XbmR2YjdOx4SJB1Z2bCgDJya+K/A/wC2vpPw /wDh14w8EftNTjwd8XvAoFvfW8cRYeJo8lYLmwH/AC080AEr1BPOK/O744fEb4m/tH/Du9/ad8Qa ja+Cvhb4H8Xafp3hTwlPMx+0Sm4iMt2rEbJ5UBKvgMF+YDgMW+8yLgDG4rHcmK9ykmlzdJ81uVQf 2ua6s1dJO77PgxGZUqdNSjq309N79rf8A/fD4ceNY/iL8CvCnjmPQtb8MrrWnx3Y0rWIvKu7XcPu SL2P8xg1224iRvmynTrWdpdx9s8M6ddAiRbi0ikDhepKKfy5q9u2t8x2r6Ed6/P6tWPtJcqsruyv e3l522uehFPlV9ziviV4btvF/wCzd478KXsQns9X8PXlnNGe4eFlA59c15Z+yP4sm8Z/8E4vhPrV 5bPb3keirYXKvL5hElsTA2WHUkoea9113VbPRvBesaxqU8Vnp9nYzTTzyHCRosZJJPpXyZ+wbDdj /gml4VvrqJ4IdU1nVtS08M3LW1xfzywtjsCjAgHpntXt0ZOeT1pNfDUhb/t6M7/+kr7jmkmsQvNP 81/mfZXH/LME9iDmlZxsKBCT3zziogCHyJCqZ9cmlYqGLeo/A14MpybvY6rK45WQKC2D3K9eaDhu C6ZxwF7Ux+VJATI6E9vpSA4TJfYMfJgHBpOppe47E25DNtywCnBOOBTGaMngoQTnrxR1BO4FSvJx zTCArkLtA9CM1DlLqJIdvUo20fNjt0xTSQYgAMYPRqf5Y3HdgNnrTNq7Ts+Udg386l1milYcuNp6 dT0PNOYZQDAY+1QA4YE4PuBTvu8luA3HtQqz3G4kmehA4HXHUGnbsDJDDjAbqKjXeWYnBU9BnBB+ nelypkAyMY6A8fSq9sybDs4A5BJHPrmkL/OSiv1yTjpTUYEgAITzyRg08lwCCOcYOOaXPK+qCwow 7ORsKt0+opDt3nu38vc0wBEYscgAd+gFCghc/M2eCSKXPfoKwHcJN+4dMU5d+A4YA847VGAzZTlX z3GKJEBjG5G64JDYP4+tJyu0myrINzNM/wAzDB5G7NOdg2F56YJ9BT2BCq/zDOOoxiogCUO1Srel KE76grMUn2IP+FOXlACMjBPTg03II3FSGPUAZpSEMg2gbh1BODVRqNaWGO3bdu1n3dTjqa+cvE9l YXH/AAVM+EF5PLcPdWfgTXWtrfefLRnnslaUjpux8oJ/vGvoyM7XbPK99q5xXzPrd7qQ/wCCwPw5 0u1zcWKfDDVp7wNuCxE3toqNwMFjyAGI4DY717uSylKrUt0hPy+wzlxFrK/dfmaXwum879tv9pi1 33EvkazpHEkuVQNp0ZO1e2TyT3NfRJB24yAQCQc5H/1jXy98JYVX/gor+1RdsEMjT6JGsisGwq2Q O04PYknB9a+oDjeFHyg8kjBzWmewUcVFf3Kf/puIsNfk+b/NiqT1GOnGTnJpr7i+AMDOVOeelByG xgsvHQcChW5AKNtPAx1/GvFUdbo6PMF27yVO0E8cctSncSSTg9hQCvzYwcc9etO3LvCtlvQHgVol YGwUgEbixBHGaYCwbzFIUg/LmpGOZM7QB2wMAUwA4J9OcHvSsnq2CE2ngcMfUA8/SlK5K7icjpn1 pxx5YBwXz1FMKljhhnnnHFN0+Z3uCF259eMc96TJywOTnseKdsG3AUnJ/GlIOY1A+XPU1nypILkT BUJHcc89qeM7F7E54I601lc4H81/macdzdOAo5x0oaj3DcQpx0Unr160xlZRlsjsR6CpuowMHGc5 9qiIywyM7hnHY1Ds9/yKTPz8/wCChun28H7Ofws8d3b38Fl4P+Jelahd3cD7Ps8DyiKRmYcqMPjP rivvmyuYr7S4L61kjuLO4iSSCSNwwdWAIOe/FeefGX4d2vxa/ZS8e/Da7l+zx6/o01pHOEDmGUqT G4B4yGAr5/8A2IfjFaeP/wBkjTvA+s3qr8Tvh9nQPFemyLsmieBmiSXbgbkcJ94DGcg4IxX081LF ZBBwu3h5yT8o1LOL8vejJfNd9eFS5MU0/tJW9Vv+Fj7P8vdkKQoJ6n+H0xX4L+BtI+EGufEL4rS/ H/8Aat+KHw18X23j3VLK28Pt4vms/IjW4Yw3BU9MoQARhMYwK/ef5duWzxzx/Svkz40fDv8AZj+G vwp+IPxg+I3wn8Ma7E07alrV1c6N/aFxcTSqsXRgxUNhQcYUck966uDs3p4KVWjafNV5VFwUXK6e y5k1rfprsZ4+hKaUrqyve7aX4H5bfGv9nL4P+JvGvgLwp8AviT4r+Nfxb8eXQaw1bV/EzX1po9hb qxuLqWRFb7xwg8zgZyvv6Rrni/w3rX/BEH4qfs8634StfAvxX+EthEb/AERg7CU21wkg1K3Zhlkl OGJPXcc5U5Mn7P8A+xj8StR+FS/tAfCf4mS/AHx34pkur3RtDttLjuLS10yaQvBbSb13BsAZJyBx xxXk/wC1zq/xQfwdoer/AB5+Fd78LPitHpc2hS+O9IuUm0jxdbbctZzKnKbwCylsbTntxX7NSrwx uNoYBYn2vsJqV78tSM4t6OFlGUOX3fc5mneT0Z4No04SqcnLzK2uqafVPvfXW2mh+5Xwn8SweM/2 Yfh94ptZoLiDVdAtLmN7UkxfNEv3SeSB0rv8FlKnoeMBeK+B/wDgnh8ePCnxL/Yd8MeArF4ofF/g TSYNL1ax5bMaArDcK2MESBc+oII7V936jeWelaVdajqd1b6fZW8RlluJ5AscaKMszMeAAOTmvwXP sqqZfmVfDTg4uMnZPtfT71Z+Z9Nhqyq0oyT3R8z/ALaGvT+Hf+CXPxrvLeeK3mm8Ny2sLs+07piI vl/2vmwPevXfhL4ZtfBv7L3w98LWFulta6X4es7dIlACrthX096+Idd8T6t+258dtJ8JfD6aa2/Z n8I69De+LPE3l7V8T3dtIssVlbbh80IdVZmAxwOa/R9UEcYSNFjij4VF4AA6D8q6s1oSwWXUcHU0 qOUpyXVJqKipdpaN23SavZuxFGXtK0pra1l+tvw+4Rc+wY54FSBSyqTgk+oFKoYKTuZSSCcNkU4Y WXaQFAOAe+O9fN/C3qdbfYXBLjavfPB4FM5ABG8cnPHFKSpK8qSSeD7U7BCJuweeT1FDjpqxXsMA Yxgn5j69KMFg52huOKUK4JjXDLxggU5gfm6DjJXHFTy2YXIwMKMgk98jrQQvOBk4yRihgNo+YcHs TSnIIcdc9RmpnFyu+hVyuQzAdlIyQ3el2rtXOF2jkjpmpOWBO1gvUEHtSjbgkhgB1xUcqbK5rEac ZjJO0cgGnhP3WcYAP3qUDfLycADv1xQNuCA7IvQ0Om07JCbDapGW2Fh056Ugz5eTll7HpTti7yoI PoD3p4DPwqOcdxjimqMX0E2RsAql1x8x4APX/ChWK8KHUDIz1p6H5WzGTnnn/PWlIUoexzzT5F3C 5GVG1lyCAOuTTskD5SSAc5JocL5i/wB78hQQN28KVXHGOtOUU7XEPJbgOQ2Tkimk4UkrhsY68mgL 2LbhzkEd/wDGkba0eVyBt784oSWwhF8wpwUOOR82DShW2gjHPcUzJwSBjPU56+9SoS2OCeDuG7GB VJ23G9BoLBWBUbPYV862Vre3X/BWbV7mbyFsbL4W20duApBd5r6UvyDzgRpwfXjvX0YVIUsGHAx/ u/4185+FrG9uP+CpPxX1aW5ii0+18DaJYwWi3GZJJGmvJXlaPsmCqqfUNXtZVZQru+vI/wAZRX36 nPWu+W3cz/hnZxQ/8FIP2mbuNbeMPFoO9Uhw0rfZX+Zm78YGB6Z719MFsMMfKQPTFfKPw0upY/8A grT+05pxhnML6H4duo5TKNv+ruE27Ov8Od3fp2r6yHLjI49eorfPk44mLk7+5T/9NxFhGuR6dX+b EHMZBOSeSD+lIhJIOEKDj5uT9aHXDFVYn0xQPlVQTgn2rwktNjp3HllMm5dqoT0J5pBtdVIByRg9 sUwqvPXd64p46DcSBnrVNaC0EIyfvlfVm4x9KeVwpLNk8kcDmk3bSOVH4kDk0gOXPVOc0Jq4aiZB JJ5OP4V/rQPl5B4PUmlCErxnHXqKVAC+CVPP3SRVyhpcVxoAUMSMnqecU0MFQEDcT29akJUhlwMj qcdfb61ECWPPy8dMVnF6FIVc5DBskjGOtOKnfu3keoJ4/KgA8jkEnqo4oXkH5SSDgHbmm2k7oQxe u0kE5604/cIHX3pzBQTnGSc5A60hDHAAYA9eOlYu+4yM4DHaM5/vdMf418PfHf8AZt8VP8b7b9of 9nPV7Twn8bLBCNWsbncLDxRbqhxBMi8CU4AD9+/IBH3ENqgEjdz0AyaGA3EOADnGCOtd2WZliMvr e1ovdWaavGUXvGS6p/nqmmZ1qMasbP5PqvQ+Wvg3+1V4H+JV8nhDxXDdfC34uWkKjV/B/iRTa3Ec oO1mgaQATxFh8rrkEEV7d8QPh54N+Kfwwv8AwX4/0VfEPhq8aOS5spJnjWUxsGUkoQcAgHrg1xfx g/Z6+E3x00SztviN4VtdW1CzYnTdWtpTbahY8g/urhCHUZAO3ODgcV80W/7M/wC0v8LLq4f4G/tN 6hqmh8snh74j2X9pqGzwq3IIcKAMYr2acMtrzVXC4h4eondRnzWTvpy1Ipv05krfzPcwlKpGLjUj zLuv1X+Vz77tLa2sNLs7O1ijgtYIligjQABVUAKB9AKg1TSNK1nQp9P1fTbLVNOlBE1rewrNE699 ysCD1r4hb4e/t6+IdOMeq/H74P8AgyVvvJonhKWdl9wzyd6zof2Pfi54qtvsnxa/bA+K3ibTXZTP YaBbw6UsoDAlDIoLKpxjgg471lHK8HTfNVx9NNfyqpJ+qagl/wCTIHiG1pTb+5fmz2Pxt8d/2Zfg BqGqLq2v+DvD/iO+8trjS9Ct0kv74xKI418qEbmYDCqOvSvnVdJ+LP7bHjGNPHHhvxR8H/2W7ZzI 2jXUzWeteLXBG1ZQPmitzyT0PTrmvpr4XfssfAz4OT/b/B/gXT5fEBZml1/WQb7UpSzZOZ5cnr06 V9EH+E8OCeTjGTWqzrBYKTqYKMp1elSppy+cIq9mls5SlbokyVh6k1yytGPZdfV6fgjE8MeGPD/g zwRpfhnwpo+m+HtA0+ERWVjYQCKGFAMAADv6k8mt8HsSM5yc96iBOwjYQAMHPP5U4ZBGAcE9uRXz cpOpJynJtvq3u/Pz9TtUUlZbD0+VQcYj6jB4pwRdxKrk9QGGetN3BlUk5BBG0elSDmTIzGPQ9jTS 1YmNBIZVKoWxxkcilIOCSee/PQd6b8pfn14GM5qTAZTwrcdc88U2o21BshQjaWRwB69KlZgT85JA /u00BpNy88dC2MGjOY9xOSOcZ4xSaS2FcAWUqN0hXP3CB0/pSMPnIAIUjOfel5bBLcZ4GeabgFiG Az7mpcW9U9SloMBCvtI5x1Bp+AUG0Agj5sGlCjzRgHI9RkUoVMYDHBOTnt/9ahxC40YDYBC88Z70 hX58gEEn8zTih3rk5yPlwtJuCv8A3D39qTih3BvmBHQdDnpQoCxks+A3oOlJuycAnHcdKU8dDkEZ 6889Krlt1EPLbhgKh/DrTQQCBJ1GSeOaBkKDnB68nk0xsZLnAPOfehp7JAkiTcvJ5Xjq3pUIkboh XA9R1qUA7F2nHGBhaiYk5DYGD0xjNQo6hGw5Rjb6HuO/vSswCngB/U96eTjJI5IGNp601scFiQSD jjgVUYx3BO4qv8uM4Hp0NIp34PyZB52ntTGI5cuxJOVI4A9uKdtIG5cEk4Jz+tSttUBId/l52qVz 0r518DPHP/wUw+OssTpIYfDXh+GU+WBIjf6WwTdjJXDAgHOCx9a+huEAJJGV4yTXzZ8KJ/tf7ff7 TtyYki+zX2jWYkWJiJAtiHHz9CcyH5R0xnvXs5bCLoYl32gv/TlM5qy96Pr+jOe0v7dov/BbbxjB JEYNL8VfCrT54ZAM+bPY3lwrAnthbhOO+a+ticHceGHpXy58RNH+x/8ABUz9nXxdB5a3F1omuaJe ZuPLLRGOG4Xg8PhougOeScHHH1GN4bBBJJ7kZrpzmTmsPUXWnG//AG65Q/KKDDXTlF93+Ov6i4B3 cDIxxn+tNAALD0HOe1PwckZYEdqQjceAMryc9M14ab7nRcbk4G0qcc9OtG351OSeeQTinFmLAHja eoOMe+O9AG1uG3DPpQpO2gXAjAOFwByAehpuBglw3JySO1LghyCCSTjGelLk5ABKg4OAKFrpcYim N4iQ5YdqVQAhyNzdzt4pWJVlPGBwQD1pVDEncNzE9OQAP6UShLfoIjAJyox1wAppw5UZO45yR0qN gxc7RGR2NKCCQABkdBnGKHdJDtccpcuceWvHOT1FKpwcnjAyABgZ9/SmDOSSDyBz70uAsZBbJ/i5 x+P/ANalJ67aBYdnkkkFQc+4pMdcEEHnGf50hBCgA9RycdaV12Oq9Mjgg8VOjYACRg/L7kf54qLI Vy2HO7rmn7VCkEikAOAueP4R6VLppjVhgjXduwA/97GKa6DcckMNvrkCnlfmDOSQeMlu1LlFYKFz knIzWTo7D5hu3cdpOSB16Y+lOKgpncAucYGOlOwQc42gjH0+lIEx2+YHIpew11C5HtO4ZbavscZp zEtInU9s4FSLzGQT0P50K2GKnLHPA4raNJCbAAlQFYDtwOKX5BtC7hnOR6/hS7twyxY/8BoXAQnP OPTHFVypbkjGHyMcDGMEZApeQc4J46DmlC5OdyjngEg1KCN2SwVhwwIquW6smFyDJ3AKGHHIZe1P V1GSuEX03daGL5wGyB90kdqTA3gkuSBgZxUyi0tw3DdggbA49emKCm1wCuzHTnIp64bcqEeXnJ5w SaiAO0blB5wAR96iUVqCHgFnAKPkfePU0mDu44A6jHSkDEy8KQxPzbelBX5W3uu09MmolZaDQIWK sWJ9u2KUvIEBDA+ue9NUkxj+72xQrfNjPyn3qb2Y7ClhvA5DnrxTSdjgj59pxx0NA+dS3ykdiRS7 SxyACOc1qrWQrJCfMRuUkt9KcCSoLEcjHSml8KQd4/xpQTg5wR34p26jY9sDBX6DnvSeWxUE+vTH FJjEfy556A8/nQxCgbSfwPek1poJXFLOzgNgLnA5poJy+QSPRaUqx5LZPTp/Wm/dwcYI6MDWLXZj SQ4McqeAcd+SKdkb22uAccjOKgCkOCu4k8ZNTMygNjLZHJx0p3SYmhuCwyeSOdvQD/61AYnIZVJH I5pAoaTLDGeCoNGXXcD8y55B9PetVJ30Cw4YZ/kyT7182/Aa2Mfx5/ac1pr21vV1H4kLGoicsYBB ptpFsYHgHKk8f3q+k1VmlyOxHQ9a+cv2bIoZNH+MF+kUubv4payZJHGA5SRYgRwOBsx36V6+Ak/q eIb2aiv/ACZP/wBtMKtueK9fyMf4+PY2P7Un7KeqXVzqVpL/AMJ9cWcE8CI8W6XTbobJA5wofGA6 jcDwOCa+pQG/u7TnBAbBr5a/aie2sdL+BXiCRLNpdO+LOjeT9pkwB9oZ7Y8HgnE34HGOa+pCw8zy zg4c4YiqzJy+p4V9UpR+6bf/ALchUV78/O35Il+Y53bQMdzwRTMoHz69dw4pAo8pTudXzginb8bQ mAD3xXiOXzNxACz8ZIHXnmgA7m+Vs5wT2pBu24yCOn3qOSc4J5ON3pTbATdzjLc+vWlJPmAsScDG P6UiAFgGIyR696dkl8A4Udf89qu7uPqKN20tt+XOBnoKaXbzsAEDvzxxSkAFlGQM884z9ajb7oXK up/i9KerElclJIYoAMdxSbyeSoz0bjrTdy87RweMdadnYMEZHX6UldbDsLwJMFto3dAeBR9x8jG3 NM6ttCkYPQ9qFbIZcMc989KTa11FYVmUTkkKxHXIpMbnD4ZeOflxQzYyDgg8cjpj/PWndWHzqxA7 Hg+1JpW3GN3LuG4AYPBA/OmOH2oytFwcfMM/L7e9OIKjdk4/2jmgZK5wQAMDkUad7jGLsOWzgjHI WnlSZTgg/QcUfKR/CBjkkdaVQCP4lHbbxiq1BsRG2Z7H3pSd0pAGAfYUEld20n1I9qackj58DP8A F0NErrUWl7jl2lGLAgjofcU4llkyCCNueR0pR8wXB/LvRgZwQ+AO1Qr3dxATjaFVt2e5yMUdZic4 VuMEdaaEB2ngtnkY60vy7huIVM8fN0FJrlF6DR8oLEKcdQacNwfceFJyTnNHRNu1ic/w9v8AGh8+ UxKnzP4s9DSdm9RgEPGR8hOCBUfl7sDaPTrgGlBVyO59hgUuWwTkqMdG6D2q+foPUNjI+w8Z7UKO NrHDgZHvTwzBT8xIxnrUTDOSu7kc47GlzXVhLzFzmL5d3Ytg0n32LDO7GCcjpUhDBwrsSMdhxSNg tksxBXHAwPypSf8AKMaGKHj+E8mgPhFJDMCe1B27MEnI7bqUfdJPzDjnNS3YdkHzE4yq/j0pqGQA fLuBY4z60pUiUlsHPqenvSbpNpXC55wWHb2pc99AHlXPUhTjByM0gPA5P1xTcnAx8p25pylWX/WE HHJ24wa05mIdhQrfMORxmogQVBwo9OeKkCp5JKMOexGATTD8u0MACRzmhSaY1qO3HB2EgnuOcetI zAjYOcdyePpS7jnsccHBxS4TIBKx8eucVL23AjyF2AyAnPHvQFwF5DYBP1pdykjjIA4J6UZHyqX7 Z6cU7q1mx2JCoMp5wO5IzjvTBt6qFGT1HNBUDIb5Rjnjj604feB2PtPSiNmQCr86lTzkZPevnH9l i7vtT+AvivU9RW2IufiH4ha1khk3CSEalMqN1ODhcEYHIPFfRv7uOQs5ZkHJ9eh6V8w/sgLD/wAM Xx3MPnBZ/Fmvzs0soYuX1W4YngDaOeAeQBzXuYWMXl9d/wB6mvwn/kYT/iRXk/0G/tZyXOn/ALLe h+IrGKGe60Pxx4evlSVdylBqECS5z/sO3Pavp3iRtxJVOSAOevNeA/tW2uo3f/BOP4u/2StwdUtv Dcl5a+S+xw8G2UbTg/N8nHHWvbNFuheeDdJvpHYtPYQSk45+aNT/AFozBKWBpvtUqL8KbX6/iKlp Vfov1NFSRICcEMOmKkxlWOBjPBB4oU8AEfL6DgUg+Y5YgDsDXhRTvodTdxVxnhQMilY4jKqTt7Zp vUc4BpckKOMkCtLJ6iGgNv3A/QjsaFzvOWOO/PFLnB5IAB64pSw2nqVPYVnZIYjMwTB3+XjgDnFN bOBkliB940m4efg7uPXqfwodgWbfj6Beabd9BpWYu1zGGA69QO9PLBcMUz3xnpTB13LjGeN3FPAH IGSTyNv86XPpuJi7vnDKCGPJA7f401jiRsHAPXNCsGICkgg4O7gn3pWBMfO/cfvcZppp6i6gTtUE gvnvQSpkU4zkc54phQcFSVFP/u88Hgc0OytdjsO35+VjhQOAKZwSCNqtj06/WkJKyMO/oBTi6sFV hg557ZptOP8ATCw0hhLuP3uhwaC3OVB3n1brQdpyNoYDuD+lLkjAAPXGCKWuwAC4YBgDkcAinghH 3ZAXPcZAPvUWx+AQGA56UCWNYi5YY68nA/z9apuyBjyu4YGVVujA0jkkDAfCDAOOn1piSLIuYisq 5IOHDD6cHipM7EALHPb6elLR6sBAylhy4OCMbaDtww54PGT/AAigglWKlVB9DSDJXOzPPHHX60rK +orAdjEHALeuOlO54w0q842g9aQ5wc4GemT/AFpxxvBAGSenU8VPtI2AXrJvCOy49aTJUkjKnPIJ 4oAGR0yTnGelIx2PgupYjGODV2TXcLD15bdn9MmlBym0A7gOAR1oJwGX77EHB74pu4rjkAHqM9ql x6Mmw3KmYhSc46Cg4bcApAznOf604fM5+/g96btBj2hSoGTjPU+1TKMe5S3GLhVHcngnHFPJIcAg uPUJim5UyBMMWIGTnpTSxZsrGcH1OBWemzQ9yRwoTe2XxwcDnH0pjgkjHXrhj1/+vR0X5juOeAP8 aGkULlkKsDwNuc07aDVxikhgcEZHPWpGO5QCefXFNJUgkksB6jGDSqAefUcGnppqMB8qDlvqxzmg 5HORjPBpQCSBtLemKaSFYbhLtJz17+lEvMS3HAqLkBiSfUjFJjEhPBJ4yO1ICHmyd3HcinAKoUHn BPP9aamkwFVdqblc4Oee1LgBcnByB7k0ikhGOflHYdqTcWzx14B9avdi1HEYYtnB6ZNOwxJJBAzy xNAII52gk8Fh0po3+Z98Y70W1uJgVJQjgsQQDnuQcV85fsmwTWn7FukW13FaQTx67q6TG35Ejf2h Pl27b2zkjsTivotSNwycjocnk18qfsbjT4v2TNa03TZtQkWw8feIobpLqAxGKX+1Lh2jGSd4Utjc OuPWvdwkW8trvtOn+VQ56n8WPo/0PbvippsetfszfEDSJlV4r3wxeRMrzeWozA3Vv4R715J+zP8A Gn4afEj9mX4e6b4W8eaJ4h8SWnhSz/tPTo71GvrZliVG86IHcp3KQc17t4xVH+EPiZGRJo30O5DI 65B/ctwfY+lfyu+E7jxv+y/+0f8AC7x/FdQpL9gstetL7T8vBqGnzErNFv481Qm5GGcBgntX2XCf C8c/weLo+05akJJwX8zaldP7l6b6nDjMb9Wq021dPR/h/wAE/rEVlyuBg7e5qK4uIoLaWe4mht7e MFnklkCKo9yeB+NYfhjxDpni34c6J4o0K9ttS0TVbCK8s7iPlZI5FDKQfxr8cf8AgpX+1Al5Pc/s 6+D7i7RbW4in8ZXsM2yOUFN8dkpU7j1VpOgwQOc8fI8NcM4nOcyjg6Wj+02vhS3b222SvvZHfisT ChTdSX/Dn6oax8ffgroB8QHW/ip4H0xNEnig1Zp9TjUWskqB40Y5xllIIA9RXAXv7aH7LeneIo9N uPjZ4I+1MmSUvd8SjAYZcfKMg+tfzhfAz4HeN/j/APHKz8BeB7exVnU3V7dXbFLTTLcNhp5AOTzw qr8zHjIAJr7d8a/8Etvi94Y+G+o6v4T8eeEvGuoWkDTDRoLKSwknA5KxOzMm7GSAwGTxnvX6jjPD nhvL8RHD43MnGo0tLJb6Xe6Wt92tOul348M3xNWHNTo3S/rsfuV4I+I3gn4leBIvEvgPxRo3izQp iyx3mnXKyKSpKkH0IIIOa871r9pr4FeHvj3afDTXPiX4V0vxlcxgx2Mt0MBy4jWIyD5FlZiAIydx 5wODX82vwg+Kfj/9mP8Aansb65h1rQms72NPFPh69V4xeWcwXzkng3YEnlNvVvvAhexxXHfEW3tv CX7VXjm005pYdMt/Ez3dm53GVLdp0uomyTuZxGw+Ykk7Rz0rro+C1J4ycJ4lum43g0ld+vpo9Frf dWM5cQr2aahr11P68A3yueNw4wDzmvlz4qftl/s9/Br4kXPhLxt46EHiK1Cm80/T7KW9ltAVDDzh Gp2EqQcHnBHrX0P4e1S01b4d6LrGnzxXcF7p0E0UyPuEiNGuCD3zX86X/BQ7wZqfhX/gqF4r1e4j kXT/ABTZ2ur2rKxCnbGLeX/gSmNM+xFfnXAHC+EzvNZ4XF1HFKLatZNtNK2qfdvY9TMsdLDUVUjG /qf0X6B4h0Xxd4H0rxH4f1K01XRdTto7qyu7dw0c0bruVlI6gg1rqxGNvGeMbef8+1fFP/BPrxPb +JP+CVnw0igYfbNHjn0q6RUxseGVlwT3OMHPvX2qxdckllIPcZz/AJ9a+PzrA/UMwrYRv4JSjrvo 2rndQqqrTjPurmbrXiHQ/DehSal4i1bS9FsYwTLcXtwsMePUliOKl0jXtI13SUvtF1aw1axkG5Li znWWM/8AAlJr8mP+CsW8/CP4Mgxsbb+3b0OXAKBjatgc+2e1fjx4I+KnxB+FnjJNU+H3jPxB4Zub OcvF/Zt0y27kjB3wMTEw9QV59a/TuFvCuedZPDG0sQozleycdNG1unfp267HkYzOYYeu6coXS63/ AE/4J/YGxO7nDDPO44o3rtz82OgGe3rX5jfsk/8ABQbQvi1q2j/Dv4pWtn4Z+IFyRDp2qRHbY6xJ jO3HWGU44U/KxyFJr2n9t39onVv2fv2U4b/wxCh8Z+I746Vo9xIMpYsY2eS5IPDFFUkL3bFfI1+E s0o5pDLKtO1WTsuzXdPqu76W110PQWMoOi6qleKPr2/1fStPKJf6jplgxzt+03SRlh9CQaksNW03 V7A3ej6jYalahjH59rcLKgYHBG5SRn2r+TvQ/APxo+PvxQ0eLSdN8Y+PtZ1i/ngg1S+vLh7dZlXz Jw9wzeXEQMMw+UcqAD29B07Uv2pv2N/jrD4U0/UNb+HutXyLdQaO88dxperKp6gH902cbWKlHHGe xP6JX8HeWPsqWOg69r8jVtL67Sbt58tjyY5/Hmu6b5e/9f5n9RpIAwGVW6Z6fhTssjDc4bPXK55r 8cP2v/2jJPHf/BMv4CfGr4f6tqlnfWnj22k1qxtrtrdo7uC3laW1n2HOPMXbjkHIPTmv1o8FeJbD xl8JvDPi7TXjmsNZ0qC9gZTuBEkYb+tfmma8OYrL8FSxFb7cpxa6xlB2afruj16OKhUqSguln63O D+Lfx9+E/wAEv7D/AOFm+MbLwo+sPIumrPG7ecExvPyg7QMrkn1FfHf7fHxTv9Z/4JW6N4x+EPiC /vfCuu65bJqGt6HIwjNkdxbfKhDRoXUKTxycHGa8t/4KvadPD4L+B/iaIzRyW+r31kHUHZ89uZAD 2z+74B967X9grTk8Z/8ABGHxl4TubCHxRFc6nrVkdHvHVYbgylmEO4jCqxYHJzgmvsMoyHBZflOC z5tzaqJSi7ctuaS006WT1bXoefXxVSrWqYaOmmj+7/M+P/8AgnX8efGGi/tgwfDvUrmfUPDHiOC6 n1q61XU55ntjbRB45laRiIwAWVs/eyuSNvP7R+JP2gPgn4L0u3u/FPxT8D6PDNzGZ9YjYscZyADn pX4t+E/+Cf37S/h39mv4na3/AGZZ2vjnVvDtvpuleH7PVIJJ7izmmDXltNMwCpKsahcqxRz1Jr5m 8ffslfHr4S/AW/8AiT488BWHhDw/aXsNpKzalbvcl5nCJtSMHK7iM5bj0r77OuGeHOIM1danjoQv aDjFxblLurvzS0T27nmYbMcThqKjOm31u9LL7j9/dQ/bW/ZX054zN8b/AATcSSH5RbXom2/723OK 5PW/2/f2VNEjsnT4o6brEtzIiRw6bDJLsLMBukOMRqM5JYgAAntX4mfst/sreKP2otR8ZQ6D460X wfB4dW3M7X1lJO05mDFdqoygAbcEk556V9s+Dv8AglN4y074g+G9Z8V/Fzwze2VjqcV1f6ZZaLLL 50UbhigeSTad4G0hlIwTwa+fzLgzg3LK8qGMx8lOO8fVXW0HuvP7rnTTzTG1Y3p0lZ/13P2gtbq2 v9Nhu7KeOe2uIlkgmU7kkRgCGBHVSDkYqHU9X0/Q/Dl/qusXtrYaTZW7T3d3cSBEhjUZZ2Y9AAOT T7eyt7TSrW1s7dbe2hjWOGFAFWNFGAAB0GBXmvxr0601j9kT4m6Rdx20trdeGb2N0uEMsTDyW+8o 5I9q/EcPCnWxMKbdoykl5pNpX9bH0MnaDZ5Feftx/ss2PiCLTT8XfD13cvLGiCyWSdXMhATayjBH I56DrX1jFJDPAJkw0ZUMDt5IIyD+tfxjSX08uiW8Esu4paQRIJXIXyz5Y2n/AGcE/nX9ivhSWIfC 7w3BDjyU0i3AJDDgRL3NfpXiRwPhOHIYaVCcpe05r81unLtZLe55OV5jPF8142tbb5nz98c/2w/g p+z346s/DXjvUNYfxHcWK3yWGmac9yywF9nmOVGFAAZueoU4yeK+lNE1nTfEPhHSdd0e5jvtK1C1 ju7K4XgSxSKGVvoQa/nT/wCCnW2P/gqDqixP5wk8EWJYBs+W3+kDZ7dd2K/dH9nLX08S/sD/AAb1 4xlTe+ELGQgnPPkqK5eJOFcJl+QYDH0m3Kt8V7WV1dWVvXuaYTHTrYmpSa0jt3/M6H4tfF3wT8Ff hnD4v8e6lNpuhy6lb2AkiiMjGWZwijA/hGdzHsAa3vFXxB8F+B/AsHiTxb4q8OeG9BkwY9Q1C9SC JwwyCpPXI5wK/Jb/AIK1eOb6DRfhF8NIfLbS76S61m/QPzI0IEcSsP7uZCfcivPfBuo6h+1r/wAE MPF3gTUbiHV/ij8IrmO/0Rrh1e4u7aGMvEDnqWhMkJY4yV6104HgCnXyfB5jWqOMKk+WT0fLFvlj L/wLe+ya7MirmXLWnSUbuKuvPv8Agfrr8Jfj18LvjhN4sf4Y+JU8Qw+H75bXUJlgdIyzLuR0Zhh0 YZwwyDg17CdxUAng8kcAg+lfgh/wS18f32lftseNfh7DH9p8P+JfDa6r5lxId8ctqUC7QBglkm5H UbRX74y7fMGBjGMHOMV87x1w3TyTN5YSm242i4t72a8kut+2h05di/rNFTa11OL+IPjbRPhr8D/E /j3xCb99D0PT3vr4WkBll8tOTtUcn/61eI/B/wDbE+BHxu8Xa1oPgvxRdxavpmnnULmDWdPksSLY EB5VMgAZVJAPpketcT/wUF8WX/hX/glX8SXs4oXfVo7fR5Glc5EdzMsblcfebaTgcDrzX41fs/WG sXf7Gn7ZXiqK2s/sVv8AD+CwlvJz86vJKzlI8c8x8HtyBzX0/CXA2EzPI6uMrTlGXOoRaatq4LVN a6y7q5zY3Mp0cRGmldWu+/X/AC7H9Dk3xz+DcEsiyfFLwCGiba+7WYuOAfXrjmvP9W/bE/Zk0O9S 11L4zeBIbjG7amoCQ4yRn5e3Ffzwfs6/s1eKv2lPjVf+FPCt74U8Pw6fYfbtQ1DUrYssUTO0ahY0 GWYsp4yBjmvumD/glN8T31Wx0u9+LPgWfwpERNItvplxC7nzAZItobI3KD8+e/SvYzHw+4Yy2v7D G5k4ySu1yq+v/gX3HNTzfEVY3p0brvf/AICP3As7631PRLbUbC6juLG5hSa3mTlZY3AZWHqCCCKl y5jyCgOeMn/PNVtNsYtO8NWOnR7TbWttHbxYXHyooUcfhVwNlNoQBifl3f41+KNRTaj/AF+B76eg 0DhiowSO3Jp3G5WG3FScn7y4Az0NR5+cLjCjk4NZcr7juAbIdVPPYBakDbrfBXj+E4/rTQSHY4JO Oh7+1NAG4BQAPvEd6d77iY5D8p29ySV9aedvlgkEkcHP9KaWYKQc7DyT3oJ2SkFyedwBHarV2xbi AbZk+YrgjBx3zXzH+y5ZW2jaP8a9GhuZZTafFbWZHjlPKefIs/HsfMzX063KHrjIPynk18p/s6lr X9ov9rPSPMZltfiakqbm7TaXZyHA6Dkn8ee9fQZdzPA4qPZQf3TS/wDbjnq254/P8j3r4hT/AGX4 B+NLw/8ALv4du3/1m3pA561+L37TPwUudY/4Ijfsy/E7T7aR9S8F+FbJNRUSBtmn3MKeYTtwGKSe W2cZwD71+u/x71RtE/Yh+LWqpGkhtPB1/MVKbt2LduMd6wvhv4TtNV/YE8CeDdcsEazuvA9pY3lv KoKbXtVRlPbHNe9w9ntTJlHGR2VZX80oSUl90jmxeFWIvB/y/qv8j87/ANgj9pvT/Dn/AATy+Jmi eONSiij+GNo9/ZvMzvI1i6lo4wO4SUGNQvJ6V+RGp3nib4sfGHxd4r1QM+s6k15r2sS+WTFax/fd m/uogMaZPfHvSfEfwj4k+Enx28a/DTUry8024069fTdRhiuiIru3Vt8BYKcSRtGUYbh1z0INffnw e+CNpon/AAQj+P3xh1qaSz1/xXoMi6bHPbsjwWNvKSgGTz57EvuHBDDriv6FhhMtyGvWzOm7vFzp qP8A2929W3N+SSPl/a1cVCFH+RO/y/qx6V/wSY8NCXxj8YfF81vbYis7DTrWUoTNGWDTSL1wFO5S eMkjrX7WlUIfG/BXHI6fSvx+/wCCTmoO+gfGzTiZU/4mNjcldgwC0AHLdT06dPzr9iGPUDl+dv8A Wv548V60p8TYjm6cvfblifU5LFRwcbef5n823/BS3w9p+kf8FNfElxp0Xkvq/hmx1O+IP3p9s0JP 1ZYk/wC+a+QviXZ31l4+eXUJHlurzQLS8ldmLFmltPU+yj8q++v+CmNjHL/wUNvtQkma2nHgnS/s 0UihRc5urhJBH/e2Bgx9MjNfn34k1iLXLjTZRAltLaaLbWEwD7w8kCOpfrxkEEg9K/pzgepOpkeC k9bU0n9y/wAj5DMoJYmpbuf1afAK/TU/2KvhPfRosaSeErAiPOcfuV6nua/Kn/grH4dWDx58HvFk csavNZ3umzQspDnBSdWz0wNjDH+1X6Q/siRRx/8ABMf4EiIna3gyy+VmyT+7FfEP/BWe1P8Awzn8 JNQezj/deKZ7YXOQCBJaSnZjH8W3Oc8EdDX868Dy+r8cqMduepH8JH1OZLmy5t9l+h69/wAEyZg3 /BMezjWCHcnifUtzB+XJm6n0OMD6V+hxcMrKGKkAYxzivyv/AOCVOu21z+yJ490H7ZNPd6f4tedr V4sLDHPEjIynod2CSOo9K/U05I3KrJxk47+tfN+IVB0+I8ZF/wA7f32f6nZlUk8JT9D8rf8Agq9Z z3H7JPw0v4YWkWz8aBJnA+4slrMg/Nior82v2QPgL4V/aH+MPjXwT4ivdT0bUIvCpvtH1Gym2/Z7 lZSuZFIKyIw2gqw6Zxg1+tX/AAUx8ODWP+CaWo6wm6aTw/r1jfAI23CmURuSP4gFYnGR61+bP/BN 69urD/gqDo1tDNshvfDl/BcxeeVEir5TgY/iIOcL7k1+zcFZjWpcA16mHny1KXPZ9mve6+TPAzCj GeaRjNXUrf5Hxn438DeL/hH8ZtW8HeLLO40DxJpN4I7gQSkbWB3RXFvJwSjYDo45BHqDX03+0p+0 zefHX9mL9nqw1W7afXvD+mXz+KF8vBlvEKwo/XHzRBmz3z2r7F/4KrfC3TItK+H3xg06FINWubk6 BrHlg5njKNJbyN6bGVl47SGvxouJpJobkyEbhavu4xztNfofDmKwvEeBwea1IJVIX+UrOEl6PdfI 8vFQng6lSgno7f5o/qQ/Yy+FLfCn/gnT8PNDumjl1fUbU6zqm1lYCa6JmKgj7wUMFB64HU15R/wU c+HS+M/+Cc2ua5b6baXmo+E72HV/Mmh3Sx2yNi4EbAEjMZOQeCBz619mfDm1Wz+APgm0itvsaQaB aKsCqCIwIV+Xis/4r2cN9+y/8QrK85tZ/Dl6kiFegMLZOfSv5TwmfYinxKsfJ3l7W7805ar7tD7S WFi8F7Ly/Q/lz0Xx5Lp/7JnxA+FV00Wo2N54j03W9HmhXKLPF8s7gnoGjAxjqc1+vP8AwS7+Nv8A wlH7Pmu/BnVrrfq3hKX7Xo/myEtLp8zH5BnqIn3LgdBtr8JLNiqWu8iNHtVBY84xGOa9k/Z0+LWo /BX9rPwR8RbGUrBZXqw6tGzbVmspmWO4Rj6BcSfWOv6p414UhmuUV6FNe+3zx/xpJf8AkyVn63Pj cux/scRGT2tZ+n/A/Q/aj/gqLokOq/8ABPfQ9RleRJtJ8Z2M0SgZGZQ8Jyeww55rL/4JVatNefsN +MtL2WxXTvGU23ZKxl/eRJJ86kYUZPGCcjnjpXsP7d9tF4t/4JA/ErUdK+walaiwtdTgmk+cCNJU k3oV/iA5B6V8wf8ABJvUlPw++Nuj7V823120uztbGQ8ATGPT5Otfh2EbreHdeEt6dX9Y/wDyTPoa i5c1i+8f8/8AI/XxRsjCMRvyfp9K/PP/AIKbOB/wTKuUW4uot/ifTVEcaDZIfPBw/HAHUe4FfoWd zN86AjOeTX58f8FNJCv/AATHvYkKMsvirTEcE5K4nB+X8RXw3A13xDguvvx/M9HMtMJU9GfLH/BI 29RvFXx104uWl+zaVOFCknb+9Xdnp2/Sv2wXcXXBPLcbe/1r8Nf+CSUmPjb8abY+WjvoemyZ3Hec Szggf7P9TX7mE7cYK4xkbq9/xZpL/WjEW6qH/pETkyR/7HH5/mIwXZtGQT1cnPPvXnXxPhin/Z78 c28sgRH8PXgY8I2PJbkHsfevRCeQCpYE8Y4rA8R2Y1DwVrOnyA7bmwmiw4ByGjZeh4I56Gvz3CSj DEQb6NfmenNPlaP43WnDaayPBavnS1Qbk5GIwQw/2hjrX9dvwy1i01X9nHwLqFverd21x4ftJYpi cGQGFfmx2r+RzVdMfRfFk+kTnzRaXU1o7P3MczxHPJ7KPb8K/oV/Zi/aS+DHhf8A4Jz/AAb03xd8 VvBeiaxF4fjsprTVNUSOdXj+VlZWOcDjn6V/TPjXllXFYDC1KMXNxk1ZJvdb6eh8nw1VUas1LTRH 5mf8FGp7e7/4KkeJo4J/O/4k2nQTAqB5bmOX5eOoAIOTzz1xX7bfsbakmof8EtvgbOo+SLwnbQOp Xb80a7T+HFfgX+2v4u8JeNv+CjnizxR4N8R6Z4n0K9/s9obzT7kSxZRGSRFI4+U4yPf3r9uf+Cf2 pjU/+CVHwrfdcSNb281qTMvH7udlwP8AZGMCvn/EbCSp8F5dzJpx5Fr0fI9Drymd8xrL1/M/J3/g pT4kHin/AIKe6jo1jfteR6FoWn6Utsgz5NxKzSumP7x3R/pUv/BOfx5a+Bv+CjN34C8QKqaf4x0y fQbiJo2YfaYiZERvTIMqnPevM/iel/41/wCC0ev2lqDe32o/FqG2UoVb5Y5oB1PHyrGeD6EVs/tk eGrr4E/8FWtd1PwbqN5aaks1r4o06XaFaGeQncg2cFd0RGD1EhBzX6Jh8FhqmSUMik7SqULr1XLr /wCBO55MqsliZYnopfhr+hreCRbfs0/8F2LbTUvZtK8OaN46m0iXy4iVWwvFBijYc/KPOiA7AID2 r+k9Hk8vI2tHtBB29a/nP/bj8OXeu+I/h1+0doAB8MfEzw7Yyx3KDb5Gp28ZYBv95TuHH/LMiv2+ /Zs+J4+L/wCxF8OvH/lTW1xf6UiXSOBkTxDy5MYz8u5SRmvybxQw8sZl+BzJO8uX2c/8Uej8+ZTX yPdyeShUq0eid16f8NY+Lv8Agqf4rudO/Y28E+EIFiePxH4sRrgv1RLaMzDaPdgozXkv7MXwc1Fv +CBfx61X7Mv9p+PdL1C508TR8fZreDyoW/Hyyw/3s+1eK/8ABUH4hjxR+2vpXgnTpr2WLwfoXlyo jNg314cjao6sFCrn/a4r9hvDfgS08P8A/BNKz8AWdg2nwQ+ATZrbK5Xy2NodwySTnJPPrWtfFTyP hHLqS0lWqKo/RSUl/wC2fIzVNYnHVX0irferf5n5Gf8ABKPUli/bU8Z2LSOGvPBaSBCxw5W43ZP0 D9fev39Tdkb1AOcKAcgiv51v+CXEkEX/AAUHv9Qn1S1sLW38DTpLFPN5fnEzRKOpAJUoev8Ae4r9 19Y+N3wj8O+P9I8J678R/Bml+JNTmENhYT6tF59w7HCqADwSSBj1NeV4uYacuJZRpxbbhFuyvayf 6I6Mhf8Asav3Z6pgBip5B43YOD+VMXdn5VYDGCTyaXcroQcH+8OoBpoBWXOQPbNfk8rs9joDgxup +8e3+FKVw2COg3DNRkBQdzcdznOPoaeJMLw4Ix1brSlLS9x20AnOEUAEDp0zT+A5B3KAeOOaFVGb dx6nrxR5YycYzn1zk01Zf0xXRHluNo69MHrUjFhgkBN3JGM03bzleVznrz+HpR8vl54VCOcHineK 0Bi4bcpU8kD+HHNfKP7Os8d7+1L+2BeQ+WYP+Fmwwb1znfHpFkr5z6EYr6vEmWUfNjNfLX7KMTXX w2+Lfiaex8i71z4p67O0nllTPHDctbROSQC37uJRu9BxkYNe9lrUcDipvqoR++Sl+UWctdN1IfN/ hb9Tqf2pV3/8E3vjankS3TDwTfEJHN5Jb9wT9/8Ah+vavQPh+zH4C+Cd0/2h30CzJlfrIfITLeuD XIftHWK6l+wN8Y7KRHljm8F367U+837huMHg11Xw2uftn7O3gO5DRs0nh2ydcrjrAlLGy5sqX/X2 X4xj/kVSuqz9F+p+AP8AwU18Py6T/wAFJL/UV0yOztNW8H29wk0ScXMiGVHdj/fAKDjjGO9fq18Y tBGu/wDBCPxLp9lKJyPhhHNbNZRrtkMdurgAD+E4xxXwR/wVd0SUftF/CnWNshg1Lw5eWJYn5VeO WN8Z7EqzH3xX6M/suy2nxN/4I+fDSw1GP7VFf+Cv7KvEOP3hVGhbIHGCR0r9T4gx81wzkmPk9KUl f/t3/wDYaPGwtL/a8TT/AJk/x/4c/Nv/AIJS+Kobb9qH4h+G5ZVjl1vwxbX0MDMSC1vKwcqO52yR 5Ppiv3ckBC/dBIGQV65r+YT9kjxUPgr/AMFV/BdrrErw29t4gu/DGouxAZPNdrdc9BxJHEMH+9X9 OjyxC2feQmxfmbONoHf+teD40YD2Oexrx+GrBO/p7v5JfedXD9RywvL1i2v1P52v+CmfiqTWP+Cj l9psU1s6eHvC1tZ4jfcRJIZJm3ehGE496+fP2gtH0bSNX+Dlto+mS2Xn/CHR57yKWHYzTN5/znuW Izk/Srv7QWtp8bP+CmXxAuvDsrXqeI/F8WkaS6gfvUVo7QFe2CRIc+nPavZv+CimgJ4b/bv8JaTZ W8lvp1n8N9Ps7RByqiKWVSB7AkfXNfu/D6jgaWWYB6S9k216KN7r1k/uZ83i26s61Tpe34s/az9k R42/4Jf/AAJMcjyE+DLJR3P+r9fwr5Q/4KoXNhB+xH4LsbjcL678ZwG1GDzsid3/AACgnmvqT9jn b/w69+BhjzCp8IWg+Y5528/n1+lfHv8AwVf1CNP2WvhZpk2nST3M/ixriC7EwUQeXbyblKg5YupI 6YHOT0r+fuGqalx3Ff8AT2f/ALcz6jFy/wCE1/4V+hl/8EloIx8A/jDO0U5ceJ7eP7QGO0gWqYQD sy9z1ORX61yb9zFGYhuozzX5Xf8ABJyzuof2RvineSxSpDc+NyIN3CSbLWJWYevOQT6iv1UcgjG3 cAOMNXk+J078T4t36r/0mJrkytg6f9dT5G/bm0WTxB/wS2+MFmLR7p7bRReqmzBHkMJNw9SMZr8Z f+CfEZuv+CqPgSZIJbgR2eozRtGcCMeUmHb1XBx68iv6BvivpEmv/s0+PtEgsoL+W/8AD95BFbzE lJGaJsA9xX87v7CFvd/8PR/hPFBeXGmTQxXaXEflNlzHBteJxkYG4d+MqK/QPDbEc/CWZ0L25VJ/ fDy/wnl5xG2Ooy72/B/8E/VH/gposL/8E5rZpoSLhfFmnmI+YRtJfByO/GeK/nw00wx+KLWS4SR7 VLi3aZEGW2+dHkD3xniv3C/4KoeOLez/AGb/AIeeBIryzfVdT8Qf2hLbkZk+z28bEv7fvGjX0+av w3jupLW/a6aOKfaVlaOddySeUwkCsAeh24P1r9C8G8POHDUHL7UpNel7fozzM/lF4x+iP7IdDYt4 O0kxhdhsYSgyAdvlrjivNfj3qsOhfsafFPVbiWS2S28MXkhkjdVKjym6E8A/Wuo+H2t2niX4IeEd fQwrb6holtcxKjAr80anAJr5Q/b98Zjwh/wTU+IEMTxi615ItDiRyDuFy4RyPUqpJ/Cv5iyPL518 8o4bq6iT/wDAtT7LEVIww8p32T/I/myRidEskj/1vlgtnHC+UvOfWvU5/hheW/7IPhb4r20hudKv vEN5ompRZ3rbzxjdCSAPlEiZXDHk4x1ry6fH2VWUMu7O0gc46DnvxX7EfsNeAvC3xh/4JL/HP4Va npglurjxBOzSPEDtuGt45LaWM9nQhfcEfSv7N4qz3+yMHDFNXipxUv8AC3Zv5Xv8rH59g8M69RwT 1s7fI7j9mz4maL8aP+CH/wAS/hNql3G3ibwn4RutLu4ZmLvLamJjbTgDkAgbRjOCvWvGv+CTWvzW /wC0X8T/AA+8ztDqXhiyvsEg/vInZCeeSSGH5V8TfBf4s6r+z9+1F/az2FwLeSzufD3jHSHkLCdT vinGwYCusgDqMcAkd69m/wCCdPiDT/DP/BVnw7Ym5lS21fS9R0q3SQnMpyJYlI7EKv4YNfCZ7wvL C5VnEaa/d1V7WPX3lrJffFNeTXY9ShjVUr4eT3Xuv9PzP6SiVL5LDIXmvz+/4KXQeZ/wS91S4Kgi 18TaXIxZTlQbhVz7dcV+g2C1vkkA4OSec/Wvgr/gpGVm/wCCS/jiF7qG3H9o6b8rht0rC8jIRcDA JIAyeBX89cESa4hwLf8Az8j+LPp8x1wtT0Z8I/8ABJ4yt+1H8U4guYz4WtfMbB4IuJMDPbPP1r95 PLxjPmHHvX4N/wDBJ/af2sfim6mcr/wisAKqSFbNy/Xt9M89cd6/ePGZCu18k/KcnH/66+q8XV/x k1X/AAx/9JRw5E39Tj6v8xGJ8wjGWI+Yt0z2qGZT5AKsowpGHTJ561ZUuCxBlHOeVqBtrxEOSp7k Y5welfl7irnsH8hHxa0x7b9oT4gwvBslh8b6lZ7i4Acm6kdcKOgww5/Cvpj4b/sF/Gn4sfs7eEvi R4TtvhtFoep2heOO81qWK6uF3YDygRMFJIwVBwB+nmX7XGn6Vp//AAVB+MVtosCWmmp4rDxR+WUI eSKJ5eCP75yPXJNfvl+xNFbj/gld8F/s+za+gIZQCCN2Wz1HXPX0r+t+NOMcXk+Q4TGYZK8+XSSe zi30a1Ph8ty+niMTOnLpf8H8z+cD4rfDHxL8HPjxrngXxdaaRFrumLE0yabdm4gQOu9NjEAngdCK /en/AIJ0a2E/4JRaC94XaPRtT1KF5OADHHO7A/gvHNfmz/wU00GTS/8AgpPLqaWa29prPhWzuQ6q Nsskcjxsc9yAVBP0r3f9iz4mR+Hf+CPf7SIu2ntj4ba8vI5YgMMtzaqyjnPzByRwPSvM44dTPeEM LWt705U27d5e67b9ZeZ0ZXy4XMJx6JP8Nf0Pz80r4mSaP/wUOufi/wCFtHtNXjh8ZXuuWFheXWyK VWkkVA8g6DB3ZAPUD3qj+0F8cPFnx7/aBfx74os9A03UILKOzgs9JXKwwo5dVZmO5zuJOTjg4x3r sf2Ofg/4f+NX7dfhDwN4vgmuvDIsLi81S0jnMXnJBEgCFlIIG9gTg89O9fpt+3L+yx8MPC//AATw 1DxF8NPht4c8P6p4Xvob6a70q1jhma0LBZ1kb7zrtO7Gf4RX0mZ8R5Jluf4XB1YN15RUYy6RjJ2S bb6tdr+Zx0cPiK2FnNP3U7vzf3fqeQ/Cmxn+O/8Awbj/ABD8CW63N34j+H1/LNpixqplY25W7gCg 9mjbYT9a9H/4JWfF17/4f+Ofg5qGVj0mRdb0aQz8m2uGPmRqnZUZd3/AxxXi3/BL3xja6T+0Z8TP hPrEiLH4k0VLi3ilUHe9vlJEHYkxSIcd8GvmfV73xV+xZ/wVH8Ry6bbztHo1xeQWtsrrANQ068jY 24LYxtBIPA6wgACvlcwyVY6pm2SK3NJqtSv3aV7f9vK3b3md1LE+yVDEdLcsvl/Vz0eFT+0j/wAF /mlWCe50bUPHplkVvlUWOmDGT6AvF07lq/of8RQNdfDzXbWIOWn02eNSDyMxsBj9K/C3/glz4JuP EX7aHjjx/q095cXPhzw/5YkflJbu/lLSPvx97ahOP9uv3b1K3M+hX0C3UsDyW8ke5SPlypGR7jrX 5t4tYqFPNcPgKfw4enFfPR/konq5HTvSnVe8m/6++5/IN4I+H3jvxp8RYfBfg/wtf+IPFrRyJ/Zl nIFl/cyFHOSygYbGTnjrX1t4F/YZ/azj+Mfhm6l+E3/CPiPWLa6fUdT1S1kgiMUyzbptrM7j5Dxz kkVzP7J+q3fgn/gsN8Oohf3V2V8WX2k3M7xFpJ1la5jYsMZyzKpPAxk5r+npCRwgQ4xkYxj8K/Tf EjxFzHI8XChh6UJRqQveSle92u6203vueLlWV08VT5nNqz208h1mdunRo5Qy+WBIw4BYDnA9M1Jl DnLRrxwQep70KVyRuR8dsZ2/4UElUzj1+Wv5cjzfefZ9R4DMuFHbn/GkYAMqdBnj2pEB8l8ZQ9c5 xih2UbMkgZwRmhXvq7B1sOBLdTg9ARxxSHJBJzx95cA4pAR5uATj3p2CImUMuSc9eTV2dgAlGIJI B9+DTicODtU9wT0xUKgpJgOwyM8t0qUA7QQc89Qe9JNp9gYhbCvu+UBSRgcdzXzV+yPGR+xBpFyY pYRe63rN3+8maTcJNRuGDAsScEYwO3Svo27kWKxuixYHyHyRyQApr5w/Y/lST/gnh4CcTQTBVvBu jGMn7XNnP+16++a9vCL/AITqr/v0/wAqhzz/AIsfR/oeg/HqZrf9if4sTpGZTH4QvyY1P3sW7dM1 Y+EsFxb/ALK/w1W7hitp08L2IlSIEqCIE4GecfWuW/al1ZND/wCCdfxr1ORS6QeDr7Kb9vmZiI25 9TnFfztaT+2X+0xpR0w6b8ZL+ws7eKKC3s2+zG0REVVCBXXJQAYJ3Z696+x4a4IxvEWWVFhpxjy1 Hdyvr7q00T29DhxOYU8LWXPfVdD7g/4Kxawsfiz4I6QqqwWHUrtmyDk/u1xnr/F9Pfsfqz/gmlq0 d5/wSs8P6YF2XGk63qNq7A8OxuGcEZPowr8I/jD8aPiZ8Z/HNrffErxrD4tuNMEkdiYYokt4FkC7 1iEY5DYGck103wt/am+NPwf+Gl34P+H3jqDQdBurqS5liNhFNtlkxucO3Q/LwPyzX6/mHh1jMRwj h8phKPtISUm7vl3k30vtLseHRzWlHHzryvytW8+n+R9N/wDBQH9mbWvhV+0Zq/xX8LaM8Pwy8S3S 3L3dgSU0fUHP7xHwMxrI4EiSEkbywJGVrpoP+Cl3ji5/YY1DwBqvhyO8+JMuntptt4rt7pYrcQsm xZ3jyXM4XsPlY85APHe+Iv2+vGll/wAExvh4uqadoms/FXxJNdwXk+q6WJbOfTomeP7Z5anbvLbA FOPmz2Ffl74S+HnxB+JXiS+t/BXg3xF4wu1zJd/2JpZljhZyW+dhhI85JC56dBwK7sjyWeY5bCln 9GLlhpWjO795Rdr9HZ2V7u0t2kyMRiVh6zlhZ6T6dr/1p2Pub/gnh+zpr/xB/aR0P4talpiR/Dfw fctLb3N1HldWvwjIscQIw6xlmd3BAD7QM4OO2/4KmaFcWf7V/wAOvEc0Z+xaj4YmtY2EJULJFOrF S3Qkq5IA54NYn7PH7dvxC+A9zpXwp+Lfg8T+DtHhjtEhOltp+paREGxudMYljRcnIG4hT96v1K/a g/Zz8OftU/su2NnYXltZ+I7VP7Q8J6xkmIM6fckA+9DIpww6jIPUV8hnee4/K+MqGNzOCjh2nCDi 7rl7vre7TlpttdI7KGFpVculCi7y0b9ex5D+wH8dvA2s/wDBPPwh4T1TxZpOleIvCqPpd5aancJb MVTLI0YY/vI9hX5x3yOoNfAf/BSH46+Efiv+0H4K8M+BfEdp4h0PwvaXH267sJN9u15Myo0at0JR FbJH94V88fEj9ij9ov4WaRJq3iL4b3Oo6HG2JdQ0QpqyR84BZVXzQpz12ketU/hH+yb8c/jB8VNN 8O6f4L8R+FtPmQvPrviHS5LKzsYR8pkG7Bdh0WNRkkjoMmvpMo4WyDBZrWz+GMjKD5mtY8sXL4tU 9Xq7LfXrocmIzDEVMOsM6dnout9PL/hz9tv+CdfhOXwz/wAEtvB1zOxS78Q3V1rMm6M4xLKRH1/2 FXpwa+6fmCkEg54I/vDvivxi8W/tc63+yx+2r4E/Z+099Lu/g/4B02w0jX3Fmftd2skILXBYH5DE Sr7VBBUv3xj9Bv2jv2iLH4G/sbr8VNI0u18ZPfXVrb6LbrcmOC6a4I2s0gB2oFy2cc9K/DuLeHMz xWawxHJf63Jyp+ab0Tvazs09dk9Xvb6XA4mhChy83waP5f1959C3oEttJEPkaRdg9uOTX8zvwx8X WXwC/wCCwd5qfjq4k07S9B8S63Bqd0YTnZIJGRtuM/OSgA/2hX6HN/wVY8A3HhSzdfhP45m1pogb q1+12q26OOoWQvllJ6EDOOor8e/jB4th+Jn7SHjT4hW1jc6JFreqteNZ3F2J3twyKhTePvcqeewO O1fp3hbwbmWDWMw+YUXCnVjy7rfVaWb6PtY8jO8dTn7OdKV3F3/I7n4lePfH37WP7ZMN9Y6Jd3ep apKth4e0KDcy2lurEqpOTjrvlfoO/QZ+l/2pf2Qv+FRfsU/DTxR4csf7T1bQUNn441KyttqTtMd6 XcmSThHAjzz8rZ4Aryn9nz9pnwP+zt4U+2+HvgxB4p+JDq8V14mv9eELNCzZMUS7W8qPgAgDnHOa +4NC/wCCiPgPxr+zf8T7jx/4Ig0PVrOxEdv4fa8W8t9dSfcghVio+YY+cEYAIINfV53ic+wOKw8M uwj+rUWk0nG8r+7tduyTum+ustjhw9LD1oTdaovaS9dOv9eWx5T+xf8At5aJ8Kfhfb/Cn4xjUovD FgxTQdehRpjYxHpbTxjLbFbO11yACAcYyfKf22f2stN/aH8daF4X8CNer8OtCc3MVxdReQ+p3TKQ ZjGeVRFzt3YJJJ4AGfhPWZI7zxNqGoaTpK6Npkl0zW9glwZltFPIjVm+ZkHOCecYFdD8PtZ8J6B4 +tNU8V+Ebvx5ZQN5g0RL/wCyQ3bDkLM4BZo/VB1Gc5FfQU+CMqw+ZyzenSftbN8t1bma1aW3M/W3 XzOV5pXnQWHbVu/l/XkepeJPgD4v0H9gbwd8dNQ3Q6Lr3iD7BY6c0BEiWrI3lXbEkYWR1wFxyCpH Wv1Q/wCCWMlvb/s0/FOxKldTi8ZbrsGTGFa2i8sjnngY+or40+O/7a4+M/7HUvwqj+D9z4Vhc2zQ XFtfh4rPyGVo/LTbkKCoGP7tek/sVeJ9c+Df/BPP9o342nwnPqsVjLbtp/2uYxW148S+W8eR8wKM fmOOcgCvkuLqeZ5lwxWp4ymoVJVEoRutU5xUVdO3XV+Vzuy90aWOi4SuktX8nc4r/gpJ8IY/Bv7a Fp400izgg0fxrY/aXWBSNt/b8TEjpl0KNx12Gvjz9n3x5J8O/wBtv4Y+NkiE39l+Irczg7uYZmFv NwASTtkyB6rXsfx2/bE+I3x98GL4R8WeHPAdpYQ6glzp8umWEz3tpKn/ADykbJ5AZWwOVJFfMvh2 /wBU8J/EHRPE2lxL/a2n3aXtkbvSpZoxKmSr7GTDFT8w9wD2r7ThrK8fHIIYLMI3mouD1vdWstfT T5HmY2tRWKc6MtL39Pkf2Lx3cU9ostsDLHJGrRljgkEZHH0NfBf/AAUdtprr/glD46eO6dfsmoaf cBGB2tsuoztYAc+1fD/wU/bw+PGoeA/jJ4r8U3Wj+L7fwt4Ui1HT7H+y2tE843Hlli4OSuM7vXt0 NfoZ4sgj/bL/AOCVxi8Ia3YaEPGujRSZvrdp1spQwZ4mCEHcrgrkHAPUGv5phwtjuGM6w2Jx1lTh UjeS1S2lrpfby6H2LxVLGYWcaTu2np+B+d3/AASe1S2tf2p/itpsr3H2u68NWzW5CEqViuJA+7tn 5hjPvX7xB2+Vzvz19/bivyP/AGH/ANkP40/AX9rbxJ4u+IUuj6fob6K9nGuj6otzHfyNIHBYFAyo vzEdDnr2rG/ay/bo+OPwa/bJ8RfDvwloXg/S9ItNPs5rG61q0a5nffuZpvkcAo+NoU4K4J5zivc4 vyiXE3FNRZXUjUvCLb5lbSyev3aK5x5fWjhcEnWTWr6H7GDKDYMbMnqc4proGiYJIuccf44r8cfD 3/BT3xLonwO8H6v47+F1rr2sa2NQMd3o94trb5tphGFCSEnjI3HPpgGuw8Ff8FXvAGp6qlr44+F/ inw1E8yqL3TLmK+jQd2dQQ459AeK+cq+GnEUVJ/VnJJ9HF31tor3f3HaszwratNanwL/AMFDPD8u h/8ABWvxaZrCxso9Xs9P1SH7NJnz02tEZH4GJCyYI54Uc9h+yv7C1zBN/wAEn/g5LDHhY9KaJwyb NzLIwb6/XvXn/jb4Lfsy/tzfFPwl8T9L+JMusrpGlS2N5YeHr+OKa7QtvjEpx5kRjYk8Yz0PHX7K +F3w08K/CL4F+Hfh74PhvYfDOkQGK0S8uDPKNzFmLMfVif5V7/GfEWHxvDuEy2UZKvS5eZNNW5Yy j16vR/Pc4sBhKlLFzqte672872Z+L/8AwVhsQv7Q/wAIb6KY3El14bvYVt1+YxeXNEwc4GSDnHNf H/we+Itl4Y/4J/ftVeEtRZobjXdO0uPS4tp8yaSSRoWAB7AKCT1r+jH4tfs8/B/426l4fuvib4N0 /wAU3OivI+mmZ3jEe8YdG2kbkPBKHjIU9QK4R/2MP2ZD8LPEHgpPhP4cstD1qWObUPsm+Kd3jJMe 2ZSHQKScAHA3H1NelkfiPlODyHDZfiaU5ODi20o/Zqc2nvdkuivt5mOKyrEVMTOrBqzv37W7H5H/ APBLzw+13/wUB8U69OTHHpng+ZRG8WSTcXKgHnp/qj9c1+5HxF8L6X4z+BvirwnrNjFqOn6vpM9r NbvwsgdCAGI5HOOe1Vfhr8EfhX8HdIvYPhz4H8P+ERfbReS6fahZbjb93e5+ZgOevcmvSZ7aK6gK zAOhyCGOM8dPpX5zxvxYs5zxZhRi4xioqN7X93Xo+9+p62W4N4fDeynZvW5/JP8ADDxbr/wD/bT8 LeKb6L7PrvhTxB9m1WCQO6kBjb3CsFyX+RtwIzuwpA5r9OP+CkfgKG98GfDT9oTRrUkXcKaDq0N3 aKU+zzqZIJWU4IIbjnpkd6+jvEH/AATV+Fmv/tP3nxHHi/xbpNpca3Fq0nh6yhtvswkR0corlC6x syA4ByATgjNfcPjb4b+DfiR8MrnwT468PWPiHwrcGIy6fdD925idXj6YwAyjoa/SeIfEzKp5vgMw wl5SgmqmlvddvdSe7Tba1t5nj4TKsQqFWlOyW69e58bf8E5vhqPAn/BObRdduFk/tfxpctrt35km XETAR24z12+Uin3JJ719+7N0a5hTbn5SeDUGn6Xp+kaJa6fp1jaWFnawpFbwRRBUhjQYRQBwFA4A q3sWR9zgE884Gfwr8X4hzSpmmYVsZJW55N+i6L5Ky+R9DhKPsaMafY/lm8X6lf8AwI/4K++JdcGz Ubrw18Q7nUVjt7o24ljkYzGISMDtys5UsR69M19n+Kf+Crvj260+S38I/CrwhocxXi41XVpLxkbJ /gjUAjGO/FffHxS/YG+Afxa+OWpfEDXrfxfpeu6rMk2qJpOrvDb3MgVU3lOdrFVUHbjOM9a5Rv8A gmd+zF5U6JZfEKAhMCVPFE+VPqMnH51+54rjfgzNKWHqZlQlOpCKWzsnpfaSTV/U+cp4HMKDnGi0 k35fqj44/Zm/bY+OvxL/AOCi/wAM9A+IfjzTrXwhrFxc2dxplpoK21tNMYS0Ee8ktksvBzxjHORj 9yAjbiTgn3PT2r568E/smfs5/D/xjo/iTwp8JfCmm+I9KVRp+pC3LTxFV2iTJOPMIJy/U5r6JA6q HAbuAP61+Y8Y5tlOYYqFTLaHsoKNmrRV3du9ovs0rt30PZy+lXpQarSu7kagCQkgE56npTthGdwG EG7O3FOAAYAjI/3ulHmKJdoIVc8Eufz96+PlBX0O5tsC3zbimCDyR2+lKyhGwNuWA5xmnhhtIRPb nmkOMDJwQcYPYelEYxey/ARF8rK2358DjB6ULu8zDYX5uuOKewypHrxz0xTdoC4DtkdSex7Vavtc dxJolms5YSmRJGyld2PvAj+tfJP7E1/LcfsLjTJ/IVtA8Wa9pI2sDlIdQnCZA77cDnk4zX10CFcM c5HPJ6n0PpXxP+zjpNx8OP23f2p/hYLtLrSG1m28YaWpXb5KaksnmJgAKMSxS9Oe5619FlcVVy7F Qb1XJP5JuD/9LRyVW41YPvdfr+h2v7aatP8A8E0PivYRxiWTUNPisEXHzbpp44wV/wBr5uPetDRP 2ZfgLpOqPrsPwh8CjXbyOJ7q6l0uNy0m0AnBGASck46kmsP9tJ7k/sXJaQNFHPfeNfDtqofJ3F9W tgAMd/rxX1Dt2Eo7MzYAU7ecinUzLF4PKKaoVXFTnUvZtXsqW9nqhKjTqV5OcU7JW/E/lk/bXsfD th/wUm+LuneFdMg0fSLGeK1S0giSOGJ0tkMgjVRgLlx75zX9Inw78EeDI/gX4VjtPCvhwRS6LaMw OmREEeUpBOV65r+aD9rXUYNU/wCCi3xyvIV2xnxJdIPqkUcZ/Mqa/qB+GUKW37OPgGzKy2rR+HbJ fKk4dAIUyD7iv1PxYrVqeR5Wudp8uuru/dhq9TxskhB4mvddf1Z/O7/wUI1qyuf+CmPjTSdKtLSz 07wzo1nplra20axww4ia4cBE4GWkUnoentX7r/stfDzS/hr+wZ8MPD+n2Wn290PD1tLfz2sIjN1P InmPI5A+Y5Y8mv54/wBpzVLbxP8A8FQPi/cylZrW48ai3fzMHcqNbQsPlyOQpH0r+pDRUKeD9LjV MRrZxBFxjaAgxXL4nzqYfhzK8HfeKb82ox+/WTZpk8VLFVqnnb8X/kflh/wVI+FJ1f4F+E/i/pNk z6h4ZvvsWtzRAhhYXHG9gBlgsoj69AT2zXe/8EzPiRqfi/8AYn1Xwfqhe4bwTrZ03T53YtI1pIgm iUjsE3FB14Uc19CftoWCal/wSy+OMHnQwFfDEs4eRwATHhguffGBX5sf8EovEd1F8dPi14eMswsN Q0Oz1EQuDiKVZHjPtkrtBz6Vw5fKWZeH1eE9Xh5+6/K8X+UpfI1n+5zSNvtrX+vkfuJgGJiDhe4P 8XpTTymx2XbgHa2cD/69PDDCuqLnuW6n2rB8S6zB4f8Ah5ruuzFVgsLCa6kJ/hCIzdfTivxqMZVJ ci3Z77t1P5Wv2l/FsXjD/goN8X/EkfmzQXXiq5gjZuvl2+2AcHkD922K/WP4AeENL/a//wCCE2kf CO58QReGNb8N30WmSX8Ft9oe0ezlEluzxsRnfFsyAeh61+UXwa+Hl7+0T+23o/htmltJfFOpX19e yoV3W8biWdpPmODhniGOTyeK+xP+CdXjrUfhB/wUY8XfBbxVczQwa89xpcscgZVGp2TtsIXt5kQJ z32iv6643wdsmhTwk7V8IoVIrdpRvHro9E/uPh8tqXxDc17tS6+/X+vU970r/gk34bFtB/b/AMZP E95KjkTjT9Dtocp/DtZg2049c/hXwT+2f+zRof7Ov7SvhXw14buNd1DwrqvhtLi2vtVuVmuJrmOU xz5KqABhovlAxknpX9O4P7pijgN2J9K/ID/grDokb+Bvgp4me2QXcGsXmnfaVJyFlgMoTPu0YI/3 a/NvD/xBzzHcQUqOLr88J8ytaK15W09EuqPTzPKsPTwspU42at1Zy/7Nv/BO74PfE39kH4f/ABO8 S+JviM+oeINFS7urKyvY4LaF2YgiPCb8cdCTX0/pv/BNP9mTT9J1WzvNN8a65JdhPJvLvXHFxY7e cwMuMbs85zkDFeifsHyzzf8ABKT4NrcsCyaXIEVmyQnmttzjoMdBX2EGUB1VmZsDoMH8K+X4n444 hhmeIoxxkkozkklZWSk7bW7fM7MHleElRhJ07tpd+x+d+q/8E4P2YLTwZ4gNl4U8RT6m+mSpY3F7 r1zOLaXyyVZVLgZ3AHmvw5/Z+8N6Fqn7cnw08MeNtFTW9HufEiWGq6a8ZkSYYljZSBgn50De2PSv 6zL/ACdLuGC+aohcMgbBcbTx+NfybeDdQutF/wCCiPhnULaB7OW1+I0R+zyAFowdTeMoe2QJCPSv 0Pwoz/NMzwmYQxNeU2orlbb0bUlp22T0PLzrB0KNSk4RSTev4H9CafsO/sqzQu6/Bnwx5fKnckik A9Tnd1rkf2hfg78P/hz/AMEc/jR4M8CeHoNB0C00C7v4LSF3ZRKD5hYsTknI6HIr7ehZJLVSiybW OcE4wfpXjX7RGk2+t/sR/FbSrq0jubSbwteLJHNKY0YeUSAxBBHNfjOWcSZlVzLDRxGInKCqQdnJ vaW+rtfc+grYGjGnPkgk7PZWPwe/4J2tp9x/wVA8Ipe20dzFc6PqKwrJErgOyRuCQw7DPTmv6M/7 F0QyKH0jR2ATAY2cfHt92v5hP2LPEcXhn/gpb8HNRuFWaGXUjaTeYCxU3FqQHHvuHf1Nf1EK0LRb FYFxwwDdR+Fff+ONOtTzqjOLdpU1+En/AMA83hxwlhpK2t/0R80ftX6Jprf8E0/jdbWOn2UTHwfe uv2S0QM2ELAcAelfmb/wTO/aCuNG+Ldz8C9b1C7k8Pa4H1Dw2PK3C1vAN9xGTnKpIpDAAY3bvUV+ y3xB8PW/ij4GeLPDs8Kz2eq6Pc2k0LsQrb42GPpX8mXhXxHr3wy+PGh+I9Gc2niLw7qKSwc8NNbu 0TIfRXCMp9n9q9LwyyylnfD+Py+p8XMmm+kmvdflZx+4zzes8NjKVVbbfK+v5n9hEcmUG37x7tCR jHb6V+BP/BVDRWs/22vCPiD7NcQLqfg/yhM0QVJmt7jkKepKiQZz0zxX7UfCD4o6P8V/2dfCHj/R LqN7HWrBJygfcYXxh4m9CrZBHbFfmB/wVqtbR9G+C160Uf2/7TqESyCXLCMwqSMdcZCnNfMeFDr4 HiyFCpG0nzxa7WTf5o7M8UamBcovsz4K17SbbUP+CPnw78Vw6YgvdE+J2paVc3Xl/vHiuYjIuGP8 AcAYHet79n39kvXv2iv2b/HuveBfFFjb+N/DOqJDFoGoKBFfW7wrIpWYDfE+SVG7chK9BnjvfAen XHjD/g3i+M1upjM/hDx9FqsS4x8hEMjZPfKu30r3L/gkxqVpb/GP4z6FMUW/uNIsLqBg53Okcksb LjpgHBz1+av2/O88xeAyXH4jDv36NR766OUZWd+lpPbbp3Pm8PhYVcRShLaUfxs1+h+fVrf/ABd/ Zo/aZ0+/utJ1r4d/ErQZRIgvI9vnL3RyuUuLdvutsJB/2WANf0d/swftMeEv2lvgYuvaWqaP4qsC sHiDQ5ZAZLObHDrz80L/AHkb0ODg5FRftSfs8eHf2i/2aNS8LXhh0/xRaIbvw5rKxo81ldICQvP3 on5R1zyGPQ81+Af7KPxi1z9nD9vzRr3UjHbaZNqH/CO+LLWRwUSBrjypHznAMUwDBuflLetfF16u F46yapiadPkxdFbLqt7eadnbrF6bPX0Ye0y+uqcneEuv9fj3P6lmHyYKr5n9400gkAjG4DuKbBLF PbxzQS+fFIAyOpyGUjII+owaeXYISRkjpjtX4BNo+mV0AicPzgtjqaZtVgcqCD1z3xT5CzNgq+R3 Apd5VOEyMYOe9cU4RSuyk3YgcIJhGp256npj3px+bIOBt5AHcdCaeGRItpbgD5i5z/Kk2pv8wMrY 6g9MUkrbBcaVGSp3cNjjvSYGSSzN7NzTlkJkXIX64xk0gUBiWKjJ7HjOatQaGOYHGQh3Z9cmnMQu WDtz2waQqcAYA54NOQnJIbb+PSnFxZL2HAgkbWAyvIPUU0Y3kADk845pMAluQzHk80hJ5BAz/u4G KuSkJIUKVcsrg5BH3eaQswIAw3qPWgSkZJYYx1AxmlZgx3L90cc/0pcyGl3HDYuSFbPv/nrSOHyO hwcEY6VExZmyz4x71J83l8AnnOSeQaJK7uKw0EhtrBhzjIPFOyFJLkHdjgikYYjG1fxPb3pV27QX yH7c1SqaDYp+ZWII8zGNpNfIPhWG4T/gtf8AGmSICOCT4WaE0igcysbm+Ctj2wa+vQP3rH5mLZ74 NfI3gmDd/wAFk/2g7m5YvcxfD3w8ltuIOIWlv8gY6fMPWvoshf7vFX/59/8AuSmjixW8PX9Gbn7U 5s7vwZ8JNDu2iRtR+KOiGPfycwXAuOBkZP7rPtjPOK+kbjDhtmPmbklu2a+a/wBpWMy+J/2e7Qrd P53xUshtt0VmysE7hiW6AbcnFfSMkmWIZGYBgcrgd/SuDNVH6lhl5zf3yS/Q3oa1JfI/kX+OM9xd /td/Fi4uLkXkreMNS3XDjG4JdEAkDsqqAQByF9TX9XnhC4trr4H+Hru1uYbgS6HBJHcQD5ZF8kEM PQelfyu/tF2Pkft1fGq3CtbgeK9R/wBdH5Y+dgeR2HzZz6c1/Uf4Vhsn/Zj8O2dncrPp7eGIY4ri GbbvQ24G4OOn+8PrX7R4yuE8uyy3W/4qB4WQX9rWv/WrP5TvEGoxRfGrxNqkkkl5qsPima5RSm5Z 2GpM7EgDJzgcDr0xX9c2iXP23wNo95jy2nsYZCpBUrmNTjaeR9K/ju8QxfYfH/ii2iBQ213eJC32 lpGQxXEm0hzy5+UfMeSeetf1zfC3XB4n/Zn8B+IEdZY9R8P2lwGMokPzQrk7u5zW3jjR5cNgaiWz kvvUf8iOHJXlUXp+p4l+21fW1l/wSt+Nst3Ksfm+HJIEY4GXchVH1J4r8nP+CZes3Okf8FE7vSI4 Vktta8KXUUx7x/Z5Y2B9wTKR+HvX6X/8FDru0tv+CT3xJjuZIbZ7g2sNuc/65zcJtQY6kntXwV/w SlstOvf2pfjBqt3bxzajZeH7VbCVRny45Z5fNI9yVXp2FeTwryU+AsxqTV021+EEvubv8jfG65nR S7f5n7olyF3eWxUE4x1/KvG/j7q0Oi/sX/FXVLyWCC2tfC168k0v3V/dMOa9n2vhipPDZIzn8K+O f27tcg0T/glV8XpLx4VW90tbGJHI+aSaRUXH+1k8Ad6/JOHcL7fM8NSX2pxX3yR7eIny0Zvsn+R+ QP8AwTkudE0r9uiTxX4k1/RNA0rRfCUi+fqVxHEhmn8tEQFiPmxGx45rjf2nfH3hmw/4K1a38Uvh N4k0jxHarqdjrFpdaPIY4TdwbRLEXBwS/l4ZhwRJ35rw74VfBbxz8bvjFceDPh/pdrrGrxQSXUpv HWG3hiU7dzSMrAEnAAxljn0r3fxp+wd+0f4F+Bmv/EHX/DujRadocH2i6sbbVxc3hhHLyoiIFKoO q5zjp05/r3FUcpw+fSxOIxUVOpBU/ZtpaN9t3d+h8LGpVlhVCMHo73/rsf0W/Cj4haf8WP2b/Bfx F0hHt7PxDpMN8tvIQTCzKC0ZPcqcivjn/gpbpy3P/BNK4viq79P8VabOh2g43XCx9T04btXj3/BL j4wR618CfE/wdv7lP7R8OXX9paQGc5ls7liWVQeoSTcOOACOBmvd/wDgo1FPJ/wSt8ZSwM/lw6vp klwithGjF5HuDd9uP/1V/O2Cyd5PxtSwuyjVjb/C2rf+StfM+rq1lXy6U11j+P8Aw5r/APBPHVX1 X/gk98Nla18n7DLe2O9CPnMN1Ihb6Gvtrf8Au1PzhR6EcfSvgD/gmlq9pff8EytN0yOJY7nSPEeo 2twQWJmczmTec8ZO/oOK/QFsuoGwtjpg181xrS9nn+MitP3kvxbf6nVl7vhqfovyI2HzJ2+ZcnGc DOQee9fyl/Ej7Ho3/BTHx5tuEv7WL4oSTNJGu0OP7QhdhyT6kfhX9WjBGdOpfcMjkjr2r+Tv9qCw tbD9vr45W9vBBDAniu/KrFHtUMVDZA9dxzn15r9M8DLyxuLpt7wX5nk8R6U6cvM/q4spo5dKt5Iw xWWJCoA5GVGBmuM+J9o958AfHViVhnebw/doIZjmM/uW4J9KpfBfWR4k/ZK+Guub5pf7Q8MWU7O+ fm3QqecnOf1rqPEzRJ8OPEJWCW4c6ZOPL2ff/dNgCvxpU3h8fy9Yyt80/wDgHuuXNBvuj+Q7wN4x 1z4f/FXwp428LzWsWt6PLDeWklxAJUEiRlMMmRuGCRjIr6m8Yftw/tQ+NfDMYn8c3PhvSZ5yqy+H dFayR2PAjWfD5GRnCnPv2r47toIb3VYLSVbm3hmuRHIq/wCsRXudrAZ/iAYj6iv69PD3hrw5b/DD QNMh0PTBYW1nb+TbyadGVj2xrghcYBr+r/EjP8syeeGr4rBqtKXMk3b3Urd4y7nxWT4evWU406nK tPn+J5X+zd4l17x3/wAE/fhf4g8VXd9eeJNR8OwNqlxfWxinuJ9u12K4AwSCc4Gc5r+Yf4n6f/Zv 7RXj7Toomt3svFmpWyxkYwFupCAPbDCv675Y2jRFii8mMPnCHgL+HQfSv5ZP2hvDotf+CifxN8Mm NbUt47lDTyyb2Vbl4cEt3AMm4eg47V8V4MZhSqZjjpRSip2kororvTpte2x6HENFqjSu7taX77H2 L/wTY/aDufDvxdn+CfiC/wAaB4gaS60FZulvfAbpYgc8LIuWA/vK1ezf8FV4rh/g38IL4oq2kXiC 5gLnBIeS2YoORnna3tX5M+MPB/jf4G/tINous21zoPibSLyG9s7ophZAr74LqI9GjbHUH+8pxX3x +1z8aLb45f8ABKH4DeLZG06TxJN4oMeuLb70+y3kNpKJ0VCeFJ7knIIIznNfV5pw5GlxXgs2wyTp 1W1K213F2l81+Kv1OSjjOfAVKE3rHb0utPkM/Y4tpvFv/BL/APa78AXFpKNKm09ryC6R1fZcNaD5 Qn3s/uw2cY/Gsj/gmBrEml/8FEZrOY5XXPA85Ro2yA0csbkMBnbnceTjp70n/BPS71B/AX7UmkQD 7W83gyGW1sycCWTy51JH4ACuD/4JxXYtf+CoXggJIdtz4fvYWKdD+5iJDeoBXvxkU88w/wDs+e0n tyxl83TTv98fwJw0vfwsvl+P/BP6Ts8FgisCMnLf0r+UT9qfw7beHP8Agol8Z9BsdObR7WLxHcsL Uv5nlpNEsu4HuGZmcD3Ir+q+e5W3tDLNNCiBd5LEbQo6/hiv5Rfj14ik+Jn7dvxV1zTP+Jpca74o nt9PaMY88bltIcA9sjA/Ovz7wJVRY/FT+zyK/rfT8Lnq8SqLpQ73/Q/pp/Z18U3XjT9hL4R+J721 htLvUfC1nPJDC4aND5SjAYdRxXs3mKPl5Q54AGQa4v4d6DD4W+Afg3w3bQrbRaXolraCFF4UpEoI x9c12w3kZAO3PH/16/G8dVhPF1p0/hcpW9Lux7tJNU4qW9kOBPG4uWx1IH86QgEKV5HfjtSAjf8A Nu3HpzxS4YICD15+lc6cXuXYFVQ33B170Nv80fJnjutIxABBPzA4wKeEABK8r0I7D2q7WE3YbtO3 G4gZ+bPNJuYoMbd2cVJgjqDj6cUwbTkEqcLzjrR0BMGJAwR06Ef4UoICJlmZdvTpilUbuF4wORnp Sggj5stj8KfLZ7gJtI5XJbsPSg4HUMvuzUu3Ck4OM+tIqjBYEHHWhx1AXIUYyrkfhmoyrh2AAORj IbmhtrOQVDDPyj3pWAOMlVHHTvUptboEL/GMrnPVmoJHmD5sJ1PPSmuW3nnA5yOxpoJeV98bZ/2i KGk9R2JAUVPkDYznPr/jShgTuABAOAhOAKY2CApIAxwV7U5GAXC79/oR196kVhpbcrDkAY4Jx+Xt Xyj4QWeL/gsD8dFkezf7V8ONAlWNYyJGUT36BixGCM5GAT+Hf6yJIcghnJ7ZHFfNGmNNH/wVx8YR JEoguPhbYSyzAAlil7cKqE9lG4kAdy1e5k0lGniEusPynB/oc9bePr+jMT9qS9ePxr+zdp5dIoL7 4r2SyykvuTZBPIANoxyV2ncQMHjJ4P1BJMdrSiNXCsSNp569a+Pv2y9b0jw3L+zv4g16402x0+x+ K9lNLe3lwsMVsvkTBpGZuMYJHPrXbav+1V+zhpMUM138avhzBHcfNGY9ajcMOvRSTXTjctxGKy/C OhTlJ+/sm9efy8rfcFGcFUnd22/I/n2/bF0u40r/AIKWfGTT9RCwtd6ybsFbjztqT26FfmwORtPG OOBX9Af7KGt3/iT/AIJsfBvVtUWM3U3hS2jnUqBvCrt3YGeoGfxr+df9oy40zWv+ChHxQ1Tw9qbe ItHv/ErTWV8lwJVullSIptcnBXJ2rzgAY4xX7u/saX+kfDv9hf4c/Djxv4r8J6X8QLaN4bjRP7Zg a4gZ5CyRMFY5k2kZAzzX7L4qYb/jF8Ct5x5NOvwau26S0v8AI8HJG/rtXTTX8z8Jv2q/h5P8Kf8A goN8SPDTwvHY/wBstqOnsyYR7e7/AHy7fVQxkT0+Wv1i/wCCbn7SHhrUP2cLf4J+J9Zs9N8VeHJC ujG/uwv9o2crM0axlurR4KFR0AHavXP20v2P9L/aB+HFn4n0LVPD/hjxzoMMjPrGqQvsvLVUdvs0 0incqKTvDYO0jpya/nOmt7vTNelso7i0vntZW8q706Rpo32niSJ0AYjjIYYOPSvfy6eB464ajh5z 5atPl5nbWMkrX81JX0v17o45OplmNcrXi7/d/wAA/Zj/AIKl/GLSrnQfAfwj0XWdOvbs37avrttZ zLIY1RCLZJcHjdIdwXqdnpmtn/glX8NNQsPh/wDEH4tXrtBZa5NHo+lRoVxNHauxlk9ceYzL77a/ GTw7omseLvHmn6ZZS2s2pX9wES4v7zy4Y2P/AC0mlc/KigZLEngADsK/pI/Z/wDGXwD+DP7M3wn+ EOmfFHwRqeryBLCAWGpxzm71B1Mkp+X7u5t2CcA8Dqa8bjHL1w/wrTyjC3nOb95qO6T5pSsr22S9 PQ6svm8ZjnXkrKO35L9T7RwjZVGLZwcY9K/M/wD4Kj67caf+wd4V0VJtsWqeMrWO4iJAMqRK83Ax kgFASR0xnpX2Z8Svj98IPhNe20HxD+IHhzwzfXMbSRWV1cg3EiqBuYRrkgDI5I71+NP/AAUQ/aC8 MfGzXfhno/ww8Q6d4l8H2EF1fXFzYyh9t2wWJRIv3oysbvgMOc5HQ1+a+GvD2Mr55ha7pP2cW5cz Tton12vc9bN60YYWcb6v7zv/APgkzZmTx38ctQeAyKbDS4fOJPrI5UenJz+NfsT4o0PTvFXw21/w zqRabT9VsZLO5RJSp2SKVPI5GM9favxt/YG+JPw1/Z6+FHxZ1b4seJj4KutSvrU6TBqdlNbXGqwR W4y1vA4DyfOSuQCAcc81+wvgDx74M+LfwV0Xx34J1e313wvqsBe0uUQo4wSrI6tgq4IKspGQQa18 U6OJXEVbGKElBOCUrO11GOz2vp07eROSuH1SMHq9dPmfzVfDXxDqn7I3/BT6GbWjdyxeDNfuNN1h F4e40912tIFA5/deVKF77D3Ir9u/24ryy1f/AIJEfFK8twt5b3OkW9zB7qZEZX+oBB9q/On/AIKZ /By90v8Aa/0L4i6Fomp3lh4k0Mx6sdO0uWZEurZgoaZkUjLxvtGe0ftXqHg/xzqXxD/4NuPH+k+J pdZm8QaFo0+lRi5hcPciAhrcxkjdKhTaC3PIIPSv0XPKFPOI5Rn1P4uanGdv8X6STXzR5eFm6CxG FfRNr+vSx1P/AASi16SbwB8afDTXBMVrrlrfxQiTcF82HaxC9slM57mv133jcFO8kjjL4r8H/wDg lXeeIbH9qz4gRRaBrsnhfWtCVbvVBZutrFc28rFEZ2A+YhyNq5wQc4r94VKE52gv3Gelfl3izgnQ 4mrv+ZRf/kqT/FM9XI6qng4+V/zGMsis3CHJA5PvX8pX7UenXGk/8FEPjXpt/cySXQ8XzsZCPmIl VGU/98sMZ9K/qov7y20/Srm+upJYLWBGklkcFkVVGSeOeB7V/Kl+09qMfiT/AIKF/FXX7JNRl0/U fFBNlM+nXMRnDRxrHtV0DfNtO3jkcjjBr7HwKo1nmGJlb3eRK9ut9Ff0ucXEs0qUL73/AEP6HP2N dVi1D/glz8DJIhGgi8KW1s4jP8SDYT9eOfevpG+tvO024hO8+bG0Q5weVI688c9a+B/+CeXiTQLb /gl34JtbvVjYXEF7ewSx6lfIGSRLhwxQMQUiz91cDFfoArwiFZoWhlVgH3h8jHcg/wAq/MOLcG8P neKil/y8l/6Uz2MDK+GpvyX5H8hvjTQpvDH7Vnirw7qNrPBLpvi6a0ljhulVsLfhgEk6ZKsMNxjr xiv6iNH+N/waGk2WnH4o+B1ure0jSa1fX4DIuI1JDENy3rX86fxz+DfxNT9rz4tix+HPxJ8Q2LeL r67XVLbw9dTwSQyNvHzbOcbuozwvHFcPefs6fGrTvD2k6hffBvxhbWupSJHZs+lR+Y7OpZQUzuTI H8QHp1r+mOLOFcHxJhsL7fFKm4ptbauSjfRvpb1PkMBmEsHOaUOa/wCFvkf0Zw/tdfs03HxDsPCe n/GHwjfazfTrbWUcF55iSSu21Y96jaGLYGM9/ev5/wD9s6xNp/wU0+O9o0LRL/awnQMDhla0RgQT yeVPt6V2/wANf2Mv2rtQ1fw94o0P4YS6RFZavb3NpJ4hvoLNBJDKHVpIcl/LDIM8AkdPWvc/2kP2 RPi940/bc8Sa5rPi/wCH4j1jT7WfUPEOt67FYWkFw8bRPBDDhpNsf8IPUNncc8ePwrk+RcNZtL2G NjNSg07yi2mpR7bddHrfbqb47E18Zh1em1Z9n2Z9VftJfs1RftEfsJ+BPHnhP7UfiDofhaGfTIXf fHqFs0KvLaEjjcSoZX7MAOhOfwXuL/VrXSLjw9NLqFvp6XxuZLCfKrFchfKZmQjKyAAofpjHev69 /h54dHhf4DeDfDUdzZ3S6Xo1tbGeyk3QTGOMLvTP8J6ivzh/a7/4J/r8WvirqfxQ+HHibQvDniLU Lcf2loupQeVa6ldjASRJVI8qVwNrZVgxCnAxz834e+JGHwtepgMbO1LmbhJ9Ndnps90+nXfTpzXK ak4qrSXvdV+p8bf8E29bh039ob4n291KI7ObwO087uPkAhkbkntw5ryn9jXWbKx/4K6/Da4ghjms rvVdTSB2ufJEaOkzrJk/eG0DA75r7Z/Zy/Yn+MHwdl+Jmp+MtZ8I6bqGv+DLnRNGsNMvDcTXE8il wVZggBXGCu1s5yCAOfg+D9hz9qiTxbpGlp8JtaF49rHMk6ajbrBDhRkNMH+R1PUDJz0Jr7uOOyfM MVmVsXBRqwjG/MrfDJX3V7X6PyuedKNajSoc0H7rb2fdH6dftq/tpaJ4I+EepfDP4W+INM1j4iar G1nf3Ni/mpoluykO5K/Kbg/dVM8Z3HgYr4y/4J6/s5ah8SP2lLL4l+INNgXwD4MuxJD9qQFNQ1BU /dRIDyRDnexP8WB1Bx638EP+CXniSXxZHqXx41Gz0nw0sIaPRvDWpma6uXyMpPKUARCMg+Wdx/vV +v8A4O0TwF4A8O2Pw88GWHh/w3a6faiSDRbPajxxE48woOTkjBY5ye9fmeZcRZPw7k9TK8mn7WrU +OorWSejd11S0SV0r3vc9mlhq+OxKq148sY7L+vxPQrRmZF3y7uMfM3y8+hq2GIdCVA4+QBuDWcJ Y4wrySLEucDcVGfXFNh1KwfUXtob61lukTeYFuEZ1B4BKg5H1r8L95SbPo5RNZMOGbBGOwPFP+ZI iGJJB4UVzQ8V+GotXt9Nl8R6INQnuPKitjfRiSSTGSoXOSeCcda2Ib22nnuIYL2C4lt32TJFIrsj EZwQOQcetb+8tJLQlxdy4cfOoHUDBxmnblZUJO0jrnjI9abltwBL9eCa4rx38SPAPwz8IR678QfF mg+EdFknFul9qd2IY2kIJCgnqeD0ropU5VJqEU23slrf5f8AAJe1zu1ZduG2kEdB1puAQcbT/Kvn zWf2qf2ePD/w20Xxhqfxc8Hjw7q0zxafeQ3gmWdk++AEyQR3yK841f8Ab+/ZQ0i185virp+o5PK6 dZzXDKPUhVzXtYXIMzxH8LDTl6Qk9VutjN1IR3kl8z7KYqfukZ49t1IPvFhjr6dq+Ada/wCCl/7L OmWEsthr3inxJMrYSLTtAmzJgA5DOAuOccnqDWFqX/BUX9m+00+KfTrH4k607Eb4INAaNo8+pcgH 8DXfDgnPJJNYOpr/AHWvzMJY7Dx0c196P0bDMYwCVHJyMYzQpYsMsQCcAAcYrxn4D/G3w/8AtAfA 5PH/AIZ0jxDoulteS2qW+sQLHIzRnaxGCQUz0Ir2XccnkjnGB3r5nFYatha06NaLjKLs0+jOiE4z jeLuhOVRlLZGeBjikyzOw5A6ngUgJMLhsqc8kHn/AOtSgDd1J4wPm5/GuWa6pljQ484Lk568jrUp 68fezzj+VN35OD1J43DpTSA2WCsRkcYxR8W42PCkjLIAv5/rQSPmbcgOeBvxmgZBAywySSMcfmKA pIU46e/SlbqTcMHzD2brjP6mvl/SdRtrn/gsR4tsI45Rd2XwmsTOxyFVZL+cqOmDnYx9RX1C/ABC 846k8/WvmDwSbi+/4KxfHm9aMm007wR4d0xWyuPNMt9O4wOc4kjOT617mU/wsTLtT/OcF+phWesf X/M+Pv8AgrDrMf8Awzn8LPCrWavPf+KWulnlICRrBA5ZfUk5A9MZr86Pgr+w38Y/jf8As+6X8TPA ep/Dqy0W/uZYFh1C8lhuIxE5RiwSMj7w+7nOO9fdv/BXCwZvBvwZ1fGBFqGoWpy5OC1uWHHT+H61 6n/wS6up5/8Agn7rVpJOjwW3i+8WFPLKmMNhiMnhskk8dOlfteV5/i8j4CpYzB25ud35k2tZST0v 5I+eq4aGJzKVOemnT0X/AAT86tb/AOCaf7T+lxi3s9G8FeIUmG1ZtL14osGT1ZZY16deO3vXj37Q vg9/gz/wUi1rTRa6bbSaVqOkahE9lDsQOUgdyhySMyI5znJJJ71/U58mMAq567eK/n2/4KnaFbWv 7d2k6zCrZ1bwRGZlwNryQTOqtwPvYkx+Arbw/wDEfMc+zdYXFxiouEvhTV3eL1u30TsTmmUUsLQ9 pBvdb/M/Zf4467eaV/wT9+JPiO0Z/Pj8GXNxGWm2MhNvnO49Opr+WHwr/alvqCX2iXItry20qVjJ 5oixF5KiXBIOSQ3A6nnFf0NfErxXceI/+DeTXPFU97Gt3qPwtR3nt3Z1dnhVSAzAHnoTivws+Eej 6LqPh74xNqib7jTvhhqF1pqeXu2TLJEu4HttAXnturs8IMPHBYDHc61VTlfysv1Hn03OrTt2uehf svfspa7+07rXi+z0fxHp3hWz0C0tne41HTHuY5mlziMBXXawCg85+92xX3H4M/4JSa7pnxP0nUvE fxX8OS+H7S7iuJl0nQ3iu7jy3WTywWkKoMqOeTiqf/BJvWp0+Jfxj8OOreTPpun36FTwpBeJs/8A fI/Cv21+QR4BKsOcdDXg+IniHn2WZxWweHqKMEo291N6xTbu13ubZZlOGr4eNSau/wDgn80X7ZXh u+u/+Cznj3w7DfrC+sa1pFrb3BXd5CTW8ECZXIyFIyRkcE81xv7QH7Lvxa/Z01iCfxfY2uq+Fryd Y9O8SaWT9muJSCREyk7opMDgNlT2bPFex/tgxRQf8F1tVaMtCf7f8ONvZuCfMh+b2HH6V+kv/BSe 6sY/+CWer291NEt7c63py2Ctne8gnQ/IexwCcngCvr8PxXi8FLJMNGKcK8IqV917sLNPyv8A1ucb wcav1id7OLf6n4zTeKvF/wC0B8LLTwzrl5eeJPH3gzR5JfDF5ICbzUtMQhrixbbw8kQCyxtjcwBU 55J+w/8AgmD8dW8P/HXVvgnrV+F0PxQjajoBmc/JfRqDJEgJ6SR4kwAOVbPNfK/7E9lNd/8ABUn4 KiCA3iHWrl3Ucjy1s5w2R6DePzr0v9sL4Oav+yx+3rpHxC8BqbHwvqep/wDCQeGfKDhLK6icPPZs 2cbSWZlGR+7kcYwtezxFRwGMnU4fklF1Ic8OyleW3o1zenMc+Eq1IOOKeydpemn/AA33H6j/APBR j4jah4C/4J4ahYaNrn9h634l1WHS43gJE8luxDXAjOPlbylbLdQMkYPNflr+w58C/GXxw+PEmsQ+ NfFfhDwj4LuYLp7y1nll825LbktIg7GL7oBcFW+RgCOc0z9tX9prSP2j/GXwvg8EJrM9ho2jma7s jBIom1S52KYUjxl2XBQEDkyYGea/b79lz4P2/wAEv2I/BPgZ7eKPWRZi81ydJCfPvZv3kz5PPU4A 7AADpX51Ur1eEOEI0ZR5cRXk90rru2mne0UvnI9Vw+u5ho/dj/X5/ke2WGl2Om23kWdla2yNyXgt 1iLnHLEKACTzVvUNQttM8Oahqd0xSys7Z55W6YRFLNz9AauAEoxL5JzkA5r5j/bH8dv8P/8Agmz8 W9etb1tL1FtDew0+ZThhPcfuk254Jy3SvwzAYSpj8bSop3lOSj827H0dSUadNytokfmj+yr+2344 8R/8FNL3TPHXijUNV8B+PNTuLfTLS5wsOky73azMQIBVWjXaRzklTxmv2p13R9L1Dwlqcsum2d1c m1l2Tm1RpQ4jYBlYjIYZwDX8etvPd6frVrJpt4bW+syjWsyPteKSMgxyD0w6qc1/V78CfiRa/GH9 iXwT48tJybnWdEjN0EIVo7hU2Sr1IBDg8V+zeLXDNHK6mHxmEhyQlaLS0V18L07r8jwclxssQpU6 ju1r/XofyqT+H9R1LxcmmW2n3Oq6nc6zLY2lrIS9zLM1xIAm3ONzNwfU19r/AAR/bW+OP7OnjL/h APHVnq3ifwppl19m1Hwxr4aPUdPw2WEMzksGwcqkhKkbQGAIrivgJpoT/gsj4I0y9jQvB8TL2KVJ VD7Xjkuzgj1BwfbrX0l/wVO+HvhzQf2ifh9460bSUsNa8T2d2mu3cQxHeS2+zyXYZ5lCFlLY5UAZ 4Ar9czjMMvx2ZUMnxtFTVWDkn2avt1Wieqd76dTw8PCvSpSxFKVrNJn6qeIv2ifCL/8ABNrxX+0B 8Pr461pFp4env7BdpVlnQFRFIhxh0f5WU9COa/mh8QfETx74i8Tap4h8SeLvFOra/fSGS/uH1i4j Dndub5Y2CrErMccBRkDivrH4ReNdZm/4Il/tW+CpNQe307T7uxu7QO+douWTzoVHYOyk/VjXr/8A wS80XStZ/am+LI1ez0nVbE+FIYZIL22SYsklzKCAGzhfl+Yd8ivlMiyrC8J4PMcTKHtPZz02u42i 0r2t9rXzO7FYipjKlKEXbmX46/5H1J/wTg+NnxW+I3wc1Dwj400HWNd8OaFCV0zx1e3DTLdHfgWT uw/ePGuAHBbgYYhhz+e3/BRHwxbeHP8AgrD4mvZUTUIde0rTtTCzx7o4twaBo0zwBmMNgdz71/Rt o2g6N4d0IaZ4f0bTdD0yMl0tbG3WKIEnJIVQACfpX4j/APBVnwhLaftDfCnx8hWWy1PSZtKmCgAp JBIsyZ9cqX+mPevkOAc/w2K4xqVaFNUoVoyXKu+kvvdm7Ky7HXmeHqRwKU3zOLWv4H6N/sSXE0// AASt+Ccl350rjw8keWIJCKxCdzxtx7+1fGf/AAVUsPG2m+GPhR4x0jXtbs/CsF9cWF3Y2U0sMaXb hZYbh3jYfNiMouehbgg19afsAR6Z/wAOpvhI2mSfJ9hm+0KP+e3nN5n47s1x3/BSnRLjUf8Aglz4 lvrcps0rWdPvp0MgUmNZ1DYz1POcV87k+IjhOPHomnWnHVL7UpL5NXOnEpyy3fXlT+4/JLx58UvG 2s/8E5f2avFFt4w1278YeEfGGsWianLcu84mjPm2u92PzHy8LznKkg8E1/QL8FfiDpnxX/ZZ8C/E LT5UZda0mK6mjWYZjn2gSIcdw2cjtX80aae5/wCCZl5eK0nnW3xdt4o13HaPM0sB8DoWPGc9B0r7 N/4Jn/HmLwj8d9T+EHifUjDoXidfO0RbiQCO21BM74lycKZV5CjqyMepr9J8Q+EIYrJZ1sPH3qE5 yslvGT5pL5XuvRnm5Vj3HEKM3pJL71p+P+R+43iLWbDQfB+qa3qV0IbDTbV7q6YScIiKWJJ7dK/n H+Hf7SWv63/wWk8OfGjU7l4F17xEumSWqMyxRadcZhgiAJPAHlyc9WY8Cv1Q/wCCjfxdh8BfsG6j 4StL9rTxD41uBplrHHxILYYa5kyD08sFfqwFfz0eHtXi0r4iaNrk7yW8dhqlreMY1w0axTRsSo9Q qnGK8zwj4ThUynFYmtG/tk4L/DbX73/6Sa55jnGtCEH8Ov8AXy/M+9P+Cgvivxpo/wDwUl8T2lt4 x8T22jto9jcWVnHq88EMcTK6ttjidRgsmSfzNfK2leEvjzc+IBrmieCvjJJqt3Fn+0LKx1Iy3ER5 B+0Kw3occfMQe3Wvtr/gpjoHn/HL4SfECBJJdP1/wv8AZDO5ypaJ0kCsOxKO2fXFfpj+wprV7rP/ AASz+Es11eveyQae9sJPPI2rHIyBCSc5AGPSvbqcVQyPhPB4unQjPmSg03bVJrXR31jqc31OWJx1 Sm52tr3/AK3Pxt+E37IH7UPi34heEvGun/DrVfDsS61BdnWfEV4LW4jMc6u8zRyMZv4TnOC1e6+B Pj7N8A/+C4vxb1Pxir2HgvxF4hbSPEc9xuRbAiOIw3YjXIILdc/wuDng5/d4yp5DFZCQB1kkPH+N fzH/ALeWlro3/BVH4t7rrzodQubS5kRGPymS1ClTnqcR5/GvI4S4nlxljsRhMbRjGDptLlvezlHq +q0a2V1sb4zCyy+nCpCTbv19Gf0+RSx3VlBdRESQSIHjkB4ZWAII/A1+WH/BWSyu5v2Q/hpfwWok t7TxqvnT7xmLfbSqBjuGOB7V75+wN8ZP+Fuf8E+fD9vfP5vifwmw0LWC7szStEoMUxJAzvjKNkcZ OO1eEf8ABV621CT9jr4bzQOBpsHjVPtcePmJa3kEZHsGPI61+dcHZfVy3jOjhaukoTcdfR6/Nar1 R6mY1VVwEprZo/Nv9nz9jfxr+0h8DdX8VeAtb8I6Tqui6xJpt/b6x5qNcllWVJA8ecDY6jkZJFen fFL/AIJ4fEH4R/sR+Mfin4u8c6Pf61ocSTtoWi2rvAYfMCyM1w5DZ2sCAFAGOc19f/8ABJm8lf8A Zu+K2mbdsMHimKdXCbcmW1iLAsBzgjoelfoJ+0H4S/4Tv9h/4r+EjJJbtqXhe7gSRE3lT5ZIIHfk V97xH4k5tgOJngVOKoxqQv7t3yuzav216K66M8rC5RQqYRVdbtPr1P5yf2PfgL4f/aJ/bAufhv4o 8QeItAsV8P3Gox3el+U0jPDLGm0iVWXaQ+eBnPev2ag/4Jn/ALL8egxWk+leOtQuFUCW6m8UXCtK MYYEK20Bu+BX5Wf8E3dVmsf+Cp/gkRlcajot/bzHZnhoo5DjnjlOtf0rKBjAGcjjArn8V+J84wGc wo4fEShBwTtF21bae2r22ZWSYOhVoc043dzA8K+FdB8D/DjRvCfhbS7fSPD2lWiWun2UB+WGJQAq g9Tx3PWt0Nyw+YuehZSKdscqOBGW7HnH1pWKeWox8+eW/pX4RUnOc3Kbu27t9b+Z9JGKSsgIZwN8 bHbwpz0pu84I3ZUr0x0NIQ4BZdhOOgbmlYYClByRyeorOTKQAs9wGbnj5aGQyxbypG0596PMOM7C FJxwKV3IhzgqOhycUr7aj16BkFGOGbPI3GpCSWUlUOR1zzTG5hACqOM4BzmjcHjIO3GBjHahIlgW GxsowJODzn9K+ZfgjJf6n+1b+1Vrtyki2DeObPTLEuoBZLXTLYNg9ceY8lfTwzuhJwoLcn2r5j/Z b1STxD8IfiJ4hljA+3/E7xD5eZNxKQ3z265/CIcV7eXtwwWJnbflj6Xlzf8AthhPWpBer/T9T4n/ AOCtkMw/Z9+Ed35SNbJ4rlhdznzVZ7WQAYxjb759ODXAfsOftVfs/wDwV/YGj0Hx34yGj+L5Navr 68sI7SW4kkLSHy9iqpA3IBgZ5Jr0r/grPOP+GcvhJZlXcv4weUKfuMFtZc+4PPFfD37Nv7Bnij9o b9neX4g2XxA0LwbpcmpXFnZWs+ly3cjmFtrszCRQoznAAz05r9wyLC5TieBaMM0rOlS527rq+aVl s/y6XPn8RUrU8ycqMeZ2/wAj9bfg5+3F8GvjZ8d4/h/4Tt/F1lrlxbS3FpJqem+RFOItpcKSc7sM DjFfFv8AwVe8NNNffB3xmP3dvm+0eZWjwNzqs6c+p8ojHPU16p+zF+wJ4x+Af7ZWk/ELVfiF4b8S aPp1hdQxwWemyxTyvMEUEh3ZVA254/rXoX/BSbwzLrn/AATW1DVrez+1T+HdcstScjGY4hIEkbnq ArHIr5HKJ5JlnGeE/sqq50pKzbfWV49UvI7sQsRXy+p7aPK1+ln3PmPxj4viuP8Ag1P8NzWcswkN jZ6NJtk3Hct4ImUnPC8dO3pXxB8C/DP2n9lr9qrxqLSbZpPw9GnpOyfL5l3OzuAxHB2KhwO2K27f xNqGpf8ABDDUvCMMsNnDoPxaiW6iJJN3DOgmQjnGQ7dB2XNfR37IXhiDxL/wRc/a9t7t1hFzPcQ+ a0ZO3yrGMq2RyeR0HSv1RQWS5Zi3f48Sn6KdSH6fmeM28RVprtD9GVP+CXvifRfD37TnxPs9W1vS dGS+8N2piW8uBF5zRzyj5SxAJAIyPSv2V0P40/CrxN8WrnwJ4b+IXhTxF4vgtWuJ9IsL+OedI1wG YhT2LDPpmv5PfCHhTxH468T2+g+HPDmreKtauLfzobHTrMXEr4RSz7T2G4ZI9RX6WfsU/s6fHjwV +3V8P/HHir4T+IfD/hOCwvS15KYLVYvMRUHmxhy+SVPyEZOQfp4fiRwNgMTXr5lWxahPk0h7qu4x 01bu722S+Z1ZRmc4xjRUL67+r9P1PLv+Chd02nf8FYddvkG2WCy0aZfl28ozv25P3evX9Kofto/t Uw/tH+MfBvg7wPDrEngrRPKe2E9qRLqeoOnlmVIiDIAoYoinlixOOBnO/wCCgdg9n/wU++I7yS3E qTWun3QNzP5mwGFl2j+6g2ZC9sk96+XI9G+Ivwz1TQfG1x4f8YeDJlnS70bWb/SZLdDIMlHiklTZ u6kZ6jHHIr7jhrKMJWy7LsVO0qlKmuS+ivKMb/clbyu3bY83GYmcKtamtFJ6/Jn7a/8ABPn9knXf hfBN8Xvibp50zxdf2H2XQNHnAM2mWrYZ5ZR/BPJwCo5VVAJzmvpv9sz4NW/xm/YN8ZaHHZ20viPS rc6voFzLHuMF1AC3ynkjem5CeeGPBr57/Yl/bin+NurJ8NPifHpWm/EaG236XqMBMcOuIg+cbG+5 cKMMVyQwOR6D9GPEKtceBNYgRHZpbCdQgfG4mJsDJ9a/nLifMs6wfFKxWOXLVg00l8PKnok+sWr3 7631ufV4XD4eeC5KbvFr53P5of2F/BsHj7/gpd8LYLiGz/s3TpZtcnhky3mC3jwig/3leVT/AMAr +nrdEVyTn1471/Ob/wAE3WGk/wDBUTw5Z3NlIlxPoGsWRjLBjbyLMjHLfxYClcjrX9Fqsz9R8x6k mvf8bcROed04X92MFb5ylr+By8PQX1Zvrf8ARDixkGRtyDkccde9flv/AMFT/HFtpH7I3gzwUsuL nXvEiXMimQgCC0UyuxGOfmCj6mv1EeXajMU2g9dzV/Px/wAFSvF8+uftxaB4RjIltPD/AITDIA+Q s125z9DsjHPbNfP+FWWLGcS0LrSneX3LT8Wjrzqo6eDl56feW/En7Mv9mf8ABvho/wAQm0iOfxom pp4vuZkT98llOfLMRbqEWBgxB7joO3p//BLH4rX0Xifx18GdQ1GFtLNuNe0mKQkuJd/l3Coc4CHC vgDqxPetyb/goX8G0/ZqHwu0b4bfETXEHhyLRoEeKFIpd0HltlmYcKeMkc9RX5y/sp/Eef4Qft9/ DnxLcm6isYdROl6nEu3e9vcfuQp7fK/lE49Ca/Zllub5vkWZYfMKLjJylOnffvFLta1v+3jwlUoY bF0ZUpJqyT/r+tj1bX9W8P8AwU/4Li6xqPiPdZeG9A+Jc2p3htYmkkjimgMoKhfmbJkztHcmuc/b B/aOh/aL/akh1rRzqNp4F0W0+x6Fb3sRjdmc5lmKckM5CgDrgYxzT/287SeD/gqV8UJpYjE10bC5 hJYHzEa2wGBH0/Q14/4Vtfih8INQ8F/Ge08EanaaYX+1aFq+uaGbnTpi3yB+Tt53fIWKk5yua+wy rL8NWo4TNJq9f2SjG7sruKbtpu9VfXS+h51avKDqUFpHmu/vPr3UfgNqXwv/AOCEfiv4heJ7fUdO 8UeNfEWk3A0643RGwtI7pBAHjzzIy/OQ2Nu7HUV7F/wSceFfjh8bY2iiaZ9G02RJ/wCJV82YbB7Z Gc+/NeZ/ED9se+/aC/4JRfE/wN47TRtI+JFje2V5F9hiaC21SyS5jZ9isxImUBgyZORgg88ch+wp 8Sbb4Va/+0H42kuoorrSfh817a2pJP2l4ppMfKOSAWHPYGvlMxwubYvhvMaWLhatOpolqrXp8tn2 tpf5vW530pUaeMpOErxtv99/xP6NzKW5Q5GM4HWvyn/4Kt2Rn/ZY+F+uQW5eew8YeVJIQPkjmtpV +uC238a/KjxN+1V+0b4x0wzeIfi146ktZCxA06U2kA7sivDGMhScZ3nAHJryzW/iD498TeFrqx8Q +MfFfibTBNHcvBqmqS3aq6H5XHmElcZI+Ugc8g14/CXhLmOVZlRxlavF8jfupS1umt3bv2N8bnmH r0ZU4xevp/mf0E/8E2tQW7/4JceHrXKM+na9qdu+2TLf8fTuOOwwwwPSvSv24rKXUf8AglZ8aYog R5egNOVXriNg7E/gK8f/AOCZN6tz/wAE1VtwgV7bxXqKSNwdxaUvn8mxj2r279seze8/4Jn/ABu8 m+W18vwjdu4aPerAISQccgkDAI6V+ZZm/Z8cS6fv0/vmn+Z6tP3stX+H9D8F9CuoYv8Agk78VY5Y p5hdfE/SFsJEUlIZVgRnZj2ynAJ6k+tfO0+heLPDHhLwd4+a1ubDT9bmmuNA1WKQbvPs5gshwOUk jkCnB6jnpmvqn4eaNe6r/wAEXP2itWkkVLHTvF+kXtrGV586NIfMy2efkYDHY819E/slfBmx/aL/ AOCVnxf+GuovaRa5pHi97rwpqVxEX/s64kt45Rj0RmLKwHBDHNf0bic9oZZSxFar8CqqMvJSjBX+ Tab8r9T5OOHlVlGMd+W6+TZ8UfGX41ePf2nvjV4On1ezi/tO3srbQdG0y2uN8ctzK6q0gLgYeZ9m 4dAF71N+078A9S/Z9+MuheDrxFuJ7rwbbXc1zCuI7i6KulxtGSRiTaMV9sfsPfsg/ELTf245fGfx W8B6l4Y0LwX5hso9UTEd3qTfLG0WCRLHGpZg5GPmBHIq5/wVZ0K6tfjz8HvEQt4vsdzpV5ZNOJsu 7pJHIAV7ADcQR1NeXhuKsJR4gw+TYFx9koSbs01e3Mle/ZNvvc0qYOpUw08RV+K6/wAv69DD/bTv IvEv/BKn9k3xalxaXtzdJGhnhDYObFsjJ4BBTleua+pv+CaPjPT/APh3Tqem3UqWEOi+KL2KSeeY Rx4kYTAjdgADfzjj8a+Yfieth4o/4Nnfg7rlvnHh7UrGKYqBtDpO1tIGx05br1z1r81fBnhrx/40 j1Hw74K0fxV4m8qJry80rSBLMvl5AMjQq4UjOAeCTXlUOG6WdcPVsBOp7P2dafvPpabe110lY6ZY uWGxaqtX5or8l/kf1oaH4v8ACniTVdW0vQ/EOi6xqGmsiajaWVzHM9qzDK7wpJUMDketfgR/wUut orL/AIKNXsVvLCU1TwtptxcqIsFXiklUYPfIP6V7Z/wTs+B/xx8D/tWXvizXfA+r+CfA154dlhum 1SBYDfSb1MKogbdvXLnLDgcVgf8ABVPwZHY/tGfDXxvBbRrLrGiz6bdSK5JZrdxJHx06M4/GvkeC sow2R8aLCUq6qKVN6q2+jadm/wCVvfsd2Y4iWJy/2jjazPGv+Cefxwk+Fv7b9h4d1GV28L+N9mkX iB9ohugS1tNycf3kPflfSv0J/wCCq0kp/Yj8ELA0ZiPje3+0Zl2MAIpMEL/Fzj6da/BuKLWvD+o6 Br1sJdNluAmoaRebcDfFKCkinBHyyKM/jX7N/tb/ABT0T43/APBCn4d/EaCK1bUL3xDp8d2sjAy2 t1GxjuEHo24HI9K+q4tyONDi3LszpR0nLklbulo38rr/ALdOTA4nnwFWlJ6pXXp/w/5ml/wSXut3 wn+Men7HwuuWcwct8vNqgI69flr9bdQtY7zQruzk5SeB4mAYgkMpX+tfix/wSW1sL8Qvjd4akMSN JaaffWx3HL4MsT4HTA2r+dftiOVG4kgYHPHevxbxVpypcUYnpflf/ksT3cllzYOHz/Nn8w37MscP w5/4LLfDmwuUudMttI8dXujvEwYvGG+0wojZPI/1ec+x5r+n3DjcgRVYHgk4/wAiv5d/irdyaH/w Wa8R3sDSab9j+LUFwGMm4x/6Rb5bnrwx68YNf1DQlZLcTIGcuoIbOM55zX1fjCvbVcDi3vUp/rzf +3HFkL5Y1Idn/X5E4DiEO2zacgYbNIzkxrgdR1x+tDhTb7gMsBg8dqeoORypHqRz9a/Goy6nveYz c+xhnJAxwKXOYwqqSF4wSPzo+UOASMY45xg/Shm2jdkOc/wUS5ZW1Aby0mN3HoOKXOPvmRV9MDmh cKRu3bup9KcTjcMZIPAaqaQXGYO3KBjk9+mPUmgsVZlVxx/EDTj935WByMtnNAwH+Y5GecjilFWW oXuCOUZWcnsc9QMdq+ZP2RHE/wCxdDcvpsmlyyeLdfeRGQr5rHVrndKBjo5+YeoOa+nJWxCQjMCA cHGcHH6180/ski0X9hfRJLOa/nWbW9Ylle6JYmRtSuC+3PRM/dHTHTivYwy/4Ta7/v0//Sahzyv7 WL8n+h8a/wDBWWJh+zR8JblEOyLxsyF9u7ZutJcA+xPFek/8Ez5bk/8ABMbTkkjkWzi8TamtqwIw VM5JwPTJNcH/AMFXTCP2RvhirXM8Uq+OotkQbCyf6PLnI74HI9MV67/wT0tLXQ/+CTPw3E11YoZ/ td0x+1KxHm3LsAc42n2r9Dx0/wDjXdCLV26rS++bPNoR/wCFaWn2f8j7nJ+UMWBYkcEc14Z+0p4X /wCE5/YM+LXheJsXOoeF7tYzsLbXWMspx9R2r1yTXdEt4opJNX0aKKX7jG+jUP8ATJqW/s4b7Qri 0mQywTwNG6K3BV1Knkexr8iwNeeExdKulrGSa+Tue9Vp88HHuj+P7TfEt9F8Ob/wx8j2mp3tpfyk 5yHiUdAOOec1+2v7NXhlfD3/AAbs+OtSvoGt7jxJo+s6rOA5+dH3rGfb5FHSvxX8Z6FH4Q+OXjTQ 2tZbOPQ9Y1C0S1fKsgink2Lz227ee4Ir+ha4+HF7oP8AwQOvfANi01vqcPwvdGZvlJdrfe2euM5N f1d4n42lHDYKnF2VWtBv0X9I+KyWEnOo39mL/r8z8jf+Cfuu2mif8FQPhgl5C0n9oWFzZQnzdgWR 7ZHU+/Ebcd6/pZLhlBIXOeOcV/Ml+xFr/hjQP+Cj3w48Q+LtU0PRNKs7C4cXeoyrFDbubdFT5m4B wWAz6mv2/wDGH7bP7MngyU2us/Ffw9d3KyJG8Gjlr50ZsYY+UDhQCMnt3r888ZMqxeNzyisLRlN+ zV+WLf2pdkz1uHqtOGGlzyS1726I/IT/AIKS2qQ/8FK/FrrCqGfwjYzMTgb223C7h+WOeeK/b74d aZ4d+JX7A/gKw8T6VY69oer+ELRLmC7iWaORWgVSeQQD6Ed6/F3/AIKSyeH7z9vnw5q2lanaX39p +DoYb1I7hW8orK2wMo5Q7ZScH19q/W79i3xP/wAJT/wTE+D2o+XtaHQks5vk2/NCTGSo9Pl696XH Cqx4QynEQunCyvs0+X/7UWXRj9frwavf/P8A4J+CXx++G2ofsv8A/BQPV/D/AIR1u5H9jXdrrHhf UGmLTwo5LwiU4GWVldG67kxk8mv6I/gl8VtN+N/7Dvhb4jpbqh1rR3Go2isT5Vwqsk8Y9fnDV+aX /BWDwdHFe/CH4gW1tFBM4vNGupQgBk+QTxBj1JHltj6mvRv+CWPjQ6p+yl478C3ZcpoHiD7RbbWy Fhu0DkAdgH3fzru4vtnvB2EzaSvVp2Un135ZffJJ+VzLL/8AZsfUw9/de35r8PyPif8AYULWv/BX nwYmni3tbd7jXo3jlb5hEHOFA7MML+Rr+jMBmTAQtgc4OK/m2/Zwhl0n/gu94S0eFnimtPiLrUEk wYZli23LYYg4O4FePbpxX9JZJEa8bt2BhewrwfGeF82w9RP4qSf/AJNI6MgdqEl2f6IrTybVbjYo GWZumOvFfy8+Pk8S/tNf8FZvEOlWtwY9T8TeM30q0dxkWtrbsYt+30SON3x3JGetf0g/GDx1p3w2 /Zp8beN9Vuls7TSdInuA8gyC4Q7Fx3JbHHevwV/4J06PeeMf+Co+l69dvMsumaPqGr3bouFeadgu w8HA3M/U54HNdfhWnl+XZjmijrCFot97Nv8AFRuRnf7yrRo33f8AwP8AM+2E/wCCVHwmFtiT4q/F NrrZjcJbZU3f3wvldPbOMV+fH7YP7Il3+zTrfhe/0nXNS8WeCdaje2k1Oe2iia1uxkiJhGABuTLK cdVxX9LewpGqnc8ZXAJAr5K/bU+EVr8Xv2B/GelwBE13R4P7Y0eQR7mFxbjeE6Hh1DKTjOCa4eD/ ABRzn+2KEMdX5qU3Z3S0vonok9GaY/JMP9XlKlG0lruz8Afjl8QrT4r6j8MvGk9wk3iJvB9vpXiS ILt/0m0laMSH2kRtw9RX7rfsi23hn4t/8EbPh14Y8UWFpr+gyaE+i6nYzAOrCFmiKkD7rADg9Qa/ moWVgsW0N5bKrquegODj9cZr+g3/AIJfatNf/sE6/ZNCyQad4wvIonWQEESbZOn8OCx+tfpni9l6 w3DtKVF8vsqiaa6b2t6XVvQ8jIqiqYuXMviTv+B+On7TnwYuPgN+194q8Anz5tIidb3QLmdtzTWU uTGS3dkO5CfYetfQH/BOPxH4c0n/AIKL2mj69BaTQeKPDVzplobhVdTOCJTEQwxtdQ3H+z0r3v8A 4KyaNYw/Eb4N+IUCLqFzY39nPwMyxIY3XP8AunOP96vyc8LeJL/wt440fX9IlNtqulX8V5aXCOVM csbh1BI5wcFT6gkV9Nk9WpxLwlHnladWDi3/AHleN/vVzjrKODx7VrqL/D/hj+trxd4R0C8+CXiP RLfQtCgt59HuYYo49OjVF3Rt2C8D6V/JXp+mXsqajpi+WbiDTrgyjPGLdtrEE4/u8V+3Wq/8FQPh fdfsqz3Vn4b8TRfE64sWgOgSW223hnIKGX7TzGY/4xj5iOMZ4r8xf2YfAEnxh/ah1fwxdW0WpXF9 4R1q6uCzmMKzICJBt6fvG4HvXyHhhl+ZZJg8dVzGDhFNNc391O7Xdba7PoejnU6NedJUWm/Lztb/ AIY/TX/glD4hS4/Zs+J3hySVmFn4livIQH+YLPboTx6bg3NfYP7aOs2mkf8ABLj42T3JcpceGZ7N CAT88w2LnHbLDmvxB/Yj/aBf9n/9q21h8RyG08C+IkTSvEwlH/HrIjFIrkYByUk3I3P3Wz0FfZv/ AAUT/ai8F6/8G7P4J/DzxBpniCTVporrxJf6ddCSC2to2DpB5inG+QgEjoEDZxxn5ziLg7HVeO6V SEG6dSUZ3WyUbc130d187rudmExlP+y3d6pNf5HzD8KIPs//AAQM/ageZHaE+KbaOOQ5XzHWK2HU dlPYfQ19P/8ABKHxNc3LfGzwebW2Fnb3dlqyT+Z+9LyI0LLt/ugQqc+pIri7Dw1aeDv+DXvxLqer Wey78UztqqhYCSWnu1WAnPJAUL83YDPSvPf+CYPiiLSP+CgPibQJN8aa34WlaJwQMtbzh9vuSJCc D0r6jiCCzDh/OXBXtUdv+3FTT/8ASWedg5OjisPfrH872/M/oFK5iClST/EhfBr8if8AgrLph/4V j8HNaZmBi1m7sy3UL5luzAZ9flx15r9dlkaTkPHJGOcHB4NfEX/BRLwmnij/AIJc+NrxSq3Ph+5t dYiPy7WEUo3r1yMoWFfhvh5jlhOJMJOXWVn/ANvJx/C6Pos1pOeEmvL8j8xPDvi+WT/g2z+IehQo GWD4gx2LEsJBGJbqKbdj+D73HqfrXK/8E7/Ftt4f/wCCm/h60vtRfT4te0q801Y0VttzP8skUbbf u8LIwY8DGO9cV8OdSOpf8EnP2nvB8Fsv2nSdZ0TxAjFiS0fnJC4AxjgRHn3rkf2TNV0bw5/wUr+E Osa/qFppOlW3iN/tN5O4SOINbyopYngLuIGT0zX9P4rLIf2XmtK3xOctO7pxaPkIV261Brokvxsf 1QJGpdeFVxkKTjn1NfjL/wAFYpyurfBCxMispOpTeXg5ICoM5r9Edd/ax/Zx8J3r2Gu/GHwHaXaq WEMWoLM+AT12bvQ1+Xf/AAU78S6B42vf2dfF/hjUbbWNF1PR9Tm067hkJSeFvKIZR6dPev5+8Lsq xdLibDVK1KUYvns3FpN8ktmz6rOqkHg5pSvt+aPHdQ+CsPjr/ghF4F+K/hmxf/hIfh7q2qQ6/BG5 drmykumM0mMgLsO2THZQQK+ctF+LRt/2DvG3wYv0uZVuvFdjr2kOCXRGT5blTnhAQquOeSxFfsL/ AME4tH0zxR/wTG8XeG9Y+xavpV/4l1G0vrNoseXHIAGRjn5iwO4exxX4tfHT4Y3/AMGP2pvGfw9v I59mjam8FpJKhBntWG+3k5HIMZC5HdGr9x4Yzenj80x2V4h3lRqucPRy5v8AyWTt6Ox8zi6MqVGn WjopRs/u/X9D9D/+CUPmy/tVfE5TeyRKfC9vutxGNs2LmTBJ6jb2x1zX7sHIibcSxA45/wAK/AH/ AIJV6jBb/tz+LtOZYhcXXg0vES2GAjuAWwO/3h+lfv6W/dHmRMjORyD/AIV+FeMtO3E1TzjH8rH0 uQN/U16v8z+Xv9uWzutG/wCCrXxoe2H2J/7Stb62IbIDfZ4nLDI7mLpzyK/pc+Hmt2/iX4FeDtes bwXNtf6LazrMjBw26Jck44znrX89n/BSTQrnT/8AgqTrdxchTDrGiWF3CwYHcmJIWzjkHOPfnNfs 1+xJe3Oo/wDBLL4KPdO7bPDyRIfLVMKhKgYXHAA69T3r63xGjGtwplWKv8KitPOC6+sTgyiXLja8 O7v+P/BPq3AxwGfBwe2PXinDG0cNgE7sgU0liq4b73AJ5z9aMMc/dZc8HOM1+E6taM+jsPJXYTuL Z7DnHvUW8BztJU54ynQf4VIBz0wOgwc/pTtpdiSevJX+WKrlj1C9hgUMoBDKD1bPX3pBxKNkmQDk MQM1KFGdm1SQMDJzTd4LAjaG3YGB1qopdP1C5J+8JAEqjPU+vHTPamIQq54c52tycUNlSQenXG3H fpmmhlEZCphT1xmkl0ZNh75y21RuxnpnbxXyt+xxfyX37ETytIZ9njPxDFGfKRCAurXIxtU7Rjtj tivqK5m8nS7mTcyqkLSbguQMKT0/pXzB+xcLB/8Agnx4YurJbto77UdSvZ554FiFxNNezSSyRqpP 7ssx2nrivewytk+Ib/np/lUOeTfto+j/AEPjf/grNJ/xj78JUKoUfxRcPvHADCylCg/ia/GrwJ4e +Kniu0v9K8A6X4415LMRS3dloVxMSm8lUcxI44yD8wBxzkiv34/bm+GFt8YvHXwG+Hd4b42uqatq nkfYZ/JeOePTZ3jdz3TeFBxz82M4Jr8kP2OPGmpfB7/gpp4Ks/E7PpMk1/N4W8QW9zJsMDvlFVtp wds0agf9dODzz/Qnh7mSo8JNUoqdSmpT5X196dvv5WvWx8zmVNyx6u2k7K/yX+Z45rXwR+Olh4G1 nUNf+GXxE0vQdOs2nvbvVoZI7W1jIyXLSvtGOpxzwOK/fD9j39ovw38S/wBiPTpb+/vLK+8GaNb2 XifUNRiMFuJY4QXlSRzhkwOuc/nXz1/wU++KdzoXwI8KfCqwuL+I+JZ5NQ1iSOU+W9jalS0ROc5a RowR6ZzmvhX4u6xqvwl/4JyfBn4J2V+1i3i7SJvGXju2eMJcyNK6tbwuOoQZJwPveXgggmuXG0Jc Z5LhniKapzqTfJZt2il70nda7NJaa8t2a0p/UMRNKXMktfXovx/MvePvEH7OniP/AILJ6p8QdX+I 1xdfB2fUYtavLq10maeW6vYgg+yRgLlomeNHMmCCAV75r9lfix8R/CPjT/gmD8UfGfw/8TaFr2hS eEbz7Nf2t0Fgj/dEEOQCYyOhBHGOa/Hbw3/wTz+OviD9mnT/AInW+q+FoL2900albaDc3ksV0YGG 4AygGNXKfNt2kdie9cR+xr8X5fhb+2b4e0fUY7m68LeKb7+wfEekSuptZjcOIo5WQ5VnWQbSf4lc 8nArXiDhzBZvQpVsFifaywVk43i0+XVrRK0pctr6ptWsLB4uVGUozp8vtOuvXb5anhXwp+CXxN+N d9cad8NPC0niu5sLWE30Qu7eIW6sgKswkYEqexAbmvonUP2Dfjd4P+GEvi/4haz8Nfhh4UtIxLfy 6xrjM8Oeg8uGPBYtgbQxyT3r60/YH8OWuh/8FdP2mNJhszbRaMbm1tYoQBDFE9/K4UcAgbdoUDsP pX2L/wAFBvDC+IP+CXfxCkiKpcaSkOpITYfaHHlSBjsYEGI4z+8/hHJGKvPPEXHUeIqGWUlGNOpy e803Jc6X963XTT7zPDZTTlhZVpXur6XVtPkfzs/ErT0T4v8AiLUNN8Vw+PdL86J28TWdnJFBcu0a g7g2fLIbKgMcHGR3r9Of+CcH7Sdv4R8FeOfhj4+1JrfwpomjT+JNJuJIS32GGNs3keVGSmWV1Byf mI6Cvkv9lH4uaP8AC3xT8VJNW8NXfjX+2vB0lrY6XaWJu2urhZGKZQBsIBJkvjC8etfY/wCyL+yt 4l8KfsQfGP4g+OfDk2j+Idf8H3Vh4YOolorm3tGiLSM8O0mLewBGcsVC5Axivc48rYOrlVXB5hG0 U6ahK6TlJ21iracvXS1m7djnypThiI1KT3vddl5/p5lX9ub9qD4JfHf9lnRfC/w48Upruu2PiK2v 2intHgPkhSG2FwMsM8jqBn6Vu/8ABMbwL458L3fxO8ReJ9KfTPA9/YWjQ3x1OJ4mljD+YNkbtjCY JLYI6V+ZXws+B/jf4w/D7xvq/ghbLVrrwjp1td32jtKVu7m3dCC9uPuuVKNlTjIHBzxXpv7Inxi1 b4TftieD47W7u28I+IdRj0fxFpSlmgu4bo+SshjJxvR2Q5xuxuFZY/hWjheGsTlOXT5nHVqWsle0 7aWs2vhurGlLH+0xsK9VWv227f8ADmV4W8Y6D8PP+Co//Cc2+s29/wCENK+It1qUep6OrXEUlk8k pzCAMvlZNuBnnPXGa/X/AFP/AIKc/AKxuFh0zQviZr1syHzJrfQzGo9B+8Kn2zX42y/DjR7D/go9 e/CXxJqMvhbQf+E9l0aS+sbfc1pBLO3kuiMMD/WRLyCAGr9df+HVnwbfULWST4j/ABYuIEiCzo17 CTMw/j3bMqT6DivI49pcK1J4apm0535Pd5U9V52T1+fU1yypjYwmqEU9dfL8UeM/Ej9sjV/2sPhb 8QfgH8Lvgnr17rut6E7aZJdX9rJIEicGV3jLgIdhUKQS25unFdh/wTq/Z9+L/wAK/jz8Rdf+I3gP UfB9lPodtZ2T6hNAzyuZZJWCCN24Clck4wTjkg4+wPgV+xd8Jv2ffine+MfB114q1LWrnT2sRJrN 8JxDGzBm2DHysSoya+tkRGRs/fB64r8ozzjbLaGArZXk1FLD1LXcubm5tL2u7WtFdO57OHwFWpVj XxD95dFax5D8ZvjP4G+BHwcm8a/EG5urXTDcpbWqWcBnnupn+4iIvJJ9TwB1rwDw1+2f8F/Hn7FH jj4tana+J/DfhPQdQGk63aX1l5l1G8wVUIRM7g4kBGDx3xXmn/BULSYbv9gbQNQkjZ59O8ZWbwyK P9X5gaJjnqAVYj8a/L34R39ze/8ABLb9rrw3Yagls8MWk6q8csRkMsW8LJgngEiMjd1FepwfwHlu Y5FDG1JS53VjF2dklzxi7aPWzvczx2a1qOIdNJWtf8G+/ka/if8AYA/aAu7vW/EHw88IWnifwbJM brw9JBqcNvPe2c0rPEVhkxtZUYblZhjHGelfoD+yH4U8YfscfsffFjxf+0DZw+D/AAy2pW+oJb2s v225U+UkLkrFxyQuAOetey/8E8/ire/En9gGy0nWb5b/AFvwdfvoVwzAiQwxgNbsxJJYmIrlu5zX pX7Z+gjxH/wS9+MthBAJ7iPw/JcxRlsZaLDgj346V18RcZ5jj8c+H8whFQdSMZSSfNbmWqbbV3ve 3UywmXUqMPrVJtuzaT22+/8AE/Nv9vjxV4d/aB/ZH+Ffxz+Hevx6h4K0nXbrRr7T9Qsnt7xLmbCg kNyApQ5U9mDA8c8j+xp+yD4F/aI/Y38XX3jKefTLyDxG8Whazo06/bbQKq+bFKhBVoywLBXzw2Ri sj4IeGW+KX/BC/8AaL8NRtcyaj4Z8SjxJo2xMkssEVwFwf7w3KfrX0F/wSY8TQy+GPjJ4Vj2ho7+ y1VFbOSs0Aj+n/LOvr8xxOIyThfF4bAVHGWFqJJ6XUW4yV9LP4rPTXVNHFSpQxONhKqrqav87W/Q +I/2sv2NtV/ZmsfDmrS+M7LxhoOuahLa2m3TzZzQMqNIgkwxRshcEgLzziu4+GPxL8F/sg+BfAHx L8CRQfFLxL480e4a+OsodO/su0gkCmKPYrfMZS25jncE44xX2X/wVbmsH+Bnwc07zM6hJ4tmlWPP SJbWQPx9WXmvzD+OOj2unfsf/sum3sPIa5+H9/cyy78iVmuQxOfUZzj3xXucM5nW4hyPCLMHze1l OMkrJSSU7bWa2Xw28zlxlCOExFR0l8KTXlt/n1PrT4s+Iv2K/ivp2geI/H9h4i+CHxZ8RaHb6tql 94ZsHvLW2aXJC3Mar5bswUnJUNgjODXiPhKL9h34eeM9M17WPE/xQ+PNvZsZDo9r4TTTtNmk6r5q yBWdR3XOCeoNfanhP/gnV4I+LnwK+HPxHvPGHinwTq2reENPe/03TRBdRLMIhlw7qTznkDjNflj8 afhRbfDX9uDxr8JoNbuNXs9H1i1sotQuwgkkWYQnewHygjzDxjAwOtVw5icqx0quAwuOq3gnzRv8 KT5bKTi5WWytPzQYuNWlarOjHV79+uydvwPpr9rD9sjSPjr8PdF8BfD7wpqXhfwPaxg3trqVlCkr ujKYhB5b/u4wAQykfNWr/wAE1fCuma9+3jPr1xfapYap4Z0trqxghjjMN15+6GSOYt8y4wrKU5yD k44P3jov/BL34AmDSrq81z4k6igtkaeBtYCpOSoJO5ACB14FfRPwg/Y2+BPwK+Kc/jPwH4d1m38Q tbNbQXeoavNd/ZonKlo41YkDoOeuM18ZmfiBw1hsirZZl7neUWk+W9297uXfq+22qO6hlmMnio1q 0Vo+/wCVjhPH37fn7Ovw5+Jev+Edf8QeJp/EWkXJtLyyt9CnZTKoBZVbbtJ5HOcc18qfGf8A4KL/ AAM+IvwB8ffDa28HfEFode0Oewg1S5sI/ISSWMhWdC+/CtjoPpX5z/tFaPd6/wD8FOfib4c02ZHu 9V8fPY2r3BKR+dM0MalyM7UDMMnnivvHSP8AglD4vS0ga++NXh6ITIqXsEPhQyFM53KkjycgdiRy R+FdVPg/g7JaWFxWOryjOSUo3b3Vnoox6PuEszx1eU4U4JpaP8u5+fvwH8OfEXxxa/EH4bfDTRrv xN4n8U+Go4bmyh1FbcRW0UymWaRnOxgGYfL94gkjvXjuo6Xcaf4j1XS9SgnW/tNQmtrhYyjxK0bs jjoC2GU9sEc4r9/v2Zf2Drj9nb9py0+IjfE2PxUF0a60+5sl0JbYOJXjdGVw3RdhyDnOeMdD+TH7 UHgW5H/BX7x94Liuk0z+2fHFtHDevH+7iS/EWJSoIyFbdkZGcdea+8yHjjA5pm9ehhZKVOMFPmSk ndPlad0tla1l/wADy6+X1KNGEppp3tb8TG+Dn7N/iX4veGnufAXj34UnxMtzt/4RK91ZrLUnGeGA KFeQCRgHgV+hnxE/YG+NHj39mz9mjwrB4g8HWWoeCfD13Ya62oSyYtJJnRlEWwfvgNu3qvr7V+eX 7QH7OPxR/Zq+ImnSeKYReaTPebdB8XaTIY4p5E+cbDnfBOoXdtz2+Ut0r9if2Cf2uj8bvh1/wrrx 7qUNz8VdEtfMjuzHt/tmxQhRcHHHmrkLIB1OGAwwr5rjrN83o4Wlm+WVIVaMW38N3G6cb3vqld30 TT3ur27Muw+HnKVConGXr5p9tP6sej/sXfs5eIv2b/2fPEWgeK9X0rVte1jW2vrgac7tbRKI0iRV LjO4qgYn1PtXwB/wVRsfAA+OPgC+sJ0j+JE2lsmr2qJ+7uNPDYgkdu0iSZCjurN6V+6BU85JX5s5 A6Gvyc/4KGfsvfFr4x/HTwF4u+FPhBfE4h0WbT9XKXkNu8J85HiY7yNy43dM4r8o4B4h+scYLH46 soOald3UY35dE76W7eaXU9rM8MqeA9lCN7W83vufBn7C/i/4f/CT9rmT4jfEb4j+HfCVjaaRc2I0 +SKSWe7E2zBBUFQoKZ9f6fsHqH7e/wCyfpeix3T/ABZ0+6RtoMVpZTTyrk4+4q5wO/pX4hfFb9jP 9oP4O/CnWfG/jLwzZ2PhjS44nvL+y1uO4AMjhAoVVDEgkZ7AHqaxv2cP2avHH7SfxH8R+HfDfiLR NDl0bT47u5m1RpSrK8jIqr5eDnKnPav17ifhPh3P5SzfEYv93FJNwlHlSXS9pa+9+KPCwWY4rCpU IU9Xrqnf9D0D9sj4n+C/2g/23dD8UfCS/wDE/ikXWmx6alrLo7wMzxyFkWBXw0gcFuoGCAO9fpj8 JP2jfh7+yV/wT8+Efw++NHiHVZPiHHpBlm8OWFmLi/06NnZo4pkj/wBWFGFBbB455r498X/sF/ED 9m34O3vx9u/ij4DuNX8FOuqQ6Y+jzSwzuhwiiR5MtIWOFUgDOO9fInwc+F/jf9qL9tiLwzBqflaz rd5c6rr2uTRGRbOPcXkmZc8ncwRATjOB0WrxGWZDnWT06EMTfCYbeX2rxi9L8qVlF3bS10CniMRh 68qjh789l01+f6n9CPwm/bS/Z5+MLSW2geOrLRNaQL5mk6+n2C4yxAG0SYD8kDKnGTX1YCJERwV2 sAQV5yOo/Cvwg/ap/wCCd2hfB/8AZAvfiT8PvE/i7xZc6EI5Nd07V4oplktc4luYgijyymdxHK7V PGea77/gm9+094m1T4gt8BPHGuXWv2E9g9z4TvL6YyTWph2+ZabycvGVYMmckYYZxivybN+Bcvr5 bUzTJK7qUoN80ZKzVrX1sr2vfVLTq7HuYbMqntVSrx5ZP7v6+Z+0KnIOCeVPUcGkDuJSpCklMg9M 0ilc5PORwMc07OVIAOfQ96/KJI9cTc2zrj0BFB2j5WCgg/LgilA+cjpxnmo5Id8g5JPZscZ/nVX6 sehKAuWZSWz0OetN4aMK2cdSMU47SgypBB5wMYpFVSc5JG7vihadBXPOvjHr83hb9k74leJLTa1x pnhm9uoi27G5YGK52jPX0rmv2bvCf/CD/sCfCHwsweOWy8K2azrIgV1kaMO+QO+WP9a7b4l+HYvF f7O/jzwzdQyy22p+H7y0ZIjtZg8LgBT69Me9cf8As6area3+wZ8IdSvbYWWoyeE7Jbm2DbvKlSMI yls8kFTn3r3Kc7ZRKEX/AMvE3/4C+X/245Wv36b7f1+hwfxp8qH9uX9lq5efyHfXtVtQHbCuG02Z 9oHdvkyPYGvyU/4KR/BSX4e/tO6Z8XfDq3dtpXjOQi7nWXH2TVoVUoy4IKl0QMMD70Xqef1T/abl ks/2iv2R7+GJpJF+KpgypA+WXS71WHPXjt7Va/bC8HeGfGP/AATt+Ken+Jfs1tbWWjTahb6jNGP9 DngG+OUZ6HIA696+34Sz6WUZhl1W14VIyhJeTqz1+Taf4HBjsMq9GqusWmvuR+IOvePfEX7ZX7bv wN8L6pGIrg2Fjot6lzIAkhjbz7+YEAkh0iAUHGScHGatf8FBrmBv+CkXi6xiif7Ppmg6bZpH5obd GiOdgx90FWxjtnNdD/wTRsLLVf8Agpha3N9EZLiz8I3l9bbWxtlZoUY4/iG04xnjNZ/7ex+0/wDB WrxTbyypsUaNEGg2llXdnoeNwz39s1+14WdHD8UU8BRjy06VBtLs5TV/yR8/NSngnVk9ZS/JH9B/ hCwtE+CPhixitAmljRLeNbNyWVI/JUbDnqMcc1/OD+2N8PdI+C//AAUx8UaZ4Wt7rRNKla01/TYx JkW7SOZGaM9oxLGSB/DyB2r+l/SBGnhTTVSWRlW1iALJ1+RfTivxW/4Kv+GUg+Lvwj8WwW1oBe6X e6bdzBMO5jZJY1b1AAk/P3r8X8IM2nS4jnQlJ8tZSur9V7yfm7Jr5n0OfUVLCxmlrG3+RU/YS8QT 6X/wWl+LGhmEhPEGkXEpczGQh4zDNkk5LbvPJ5PH0r9WP2ktIXXf2Bfi9pLh99x4VvVUxMVbPlE8 Y+lfg1+w1r9xbf8ABYH4eSrcyynU1urWaWaTLMptEJ57/wCrA/Cv6FfibA95+zh46to0uJ5pPD94 saxAF2byXwAO+a6vE+hLCcUYWrHdxpv5xk1+gsmkp4OcfN/jqfzWfsW6hc6b/wAFKfgrcWszwvca sLWYLHuV45bR9y4x6ovPbGa/pm8cj/izPi1SGl/4k90Aof737l+M9q/ld/Z58RN4V/bD+DevjzSL PxVp6yeVJtYLI/2dhn/tpyPYiv6nvHGpjSvgx4u1IxvLHb6PdSFN2QwETED6V6XjZSks5wc0t42+ al/wUY8OO+GqLz/Q/m1/Y5+Men/BvxT8R9cv9ShtLe7+HF3FDGQS092sreSiDuw3GvNP2efCniDx t+2z8J9I0Syl1DWj4psr6TJPypbzC5uJWbBwAA3PTLKO9eJW0m8KznyY5F3uF+6N7F8Dvxmv2u/4 Jn/BzwJJBP8AGNfG+n+IPG9vZyaemgWLY/sOKYhm+0Z+Zpm2DkfKBwPf9g4ux2GyLBYvMbe/USWz d2k1G9vXW54OCpzxM6dJbL+mfG3/AAUK0638O/8ABVTxpqdlFNbz3un6bqrsP3ZeRVb5lYc8+So3 dQfpX9EHw68R2Pi34E+DvEtoR9m1TRLW7jJcnh4lPU9TX4W/8FSvCK6T+2/4U8US3NxLD4h8K+Sy HoGtptpCn/dm5r3b4Ff8FD/hJ8Mv2Cvh74M1/S/Gur+MfD2hRWE9lYaaGjlaP5VxM5CYK4Oc1+T8 UZLi874WyqthKbqTilGy7WSf3ONr7HtYHEU6GNrxm7Jvr6/8E/ZIHPG8qp6YqIlhG20jbnG3PJr4 +/ZY/a28P/tO3PjS007wnqXhPU/Dv2d5be7uUmWaGfdsYMhwGyhyv09a+vznccqGAORsFfhWb5Xi svxMsNiqbjOO69VdbXWqa6n0lKrCpHmg7o+DP+Cjlpd3v/BK7xs1skk0lpqGnXTYA/dLHdRszknn AGemT7Gvxz+BlysX7K37XVsw1AvN8PrbbFbqHQhbiQFpPTaTwewzX74/tY+H4fE//BPD4v6OSTJc eGLpoiIjJtdFLr8o7givwg/Y6mg1zXfjl4Gu7S/vn8TfCa9O20KjmP5yMN3/AHnHOODX7/4YYuL4 Urxt/DqKT9Lwf/trPl85g/rsPNf5/wCZ7h/wTL+KA8J/tu698P8AULtYtP8AGenN9mWRgA17a5ZQ oPdo2P8A3wa/X/8Aai0u61r/AIJ1fGjTLSS1jnuvCV4ivOWCKfLJ5KgkD6Cv5YvC/iLWvC/jfQfE nh3UptN13TpYL2xukcgxzooIORzgkFWHdWYd6/p08OfEi0+Ov/BLW78dad5Qn1zwbci7iil3C2ul hZZoSR0KuGBFYeKuQywmeYXNYL3ZSgpf4otW+9L/AMlNckxKqYWdFvVJ/cz4M/4JfadYeJfhD8b9 EuxL9luruxM2cbTFJaBduB3xnPavGf2QvN+Bf/BcbXfhhJqj2+k3N1qGgMhzGlxsIuLXIOeQrMFG ex+leof8EmJlbXfjNF/pIZdP0l8kZiI8thj/AH+PyxXk37fGl6r8Gv8AgrLofxZ0VjENTgstdtJr eIRkz2jiOdM4AcmM85OcHntXq1I/WeKM2ymT0r01a/8AMoRt917/ACOdS5MHh6/8j/Bs6/8A4Kne Jba5/aw+GegiWRpNG8NXF5cIT8g86ZApAz1xG3PpXhH7T+hnS/2MP2KGMIAuvh1OkhKYBd3gk2n8 C1W/+ChWtaH4k/ba03xLo1xLdxaz8N7K+d2fcg3iUx7fTILZU+1e3f8ABQnwi2mfss/st+I0WaKO z0g6SyM52KXtUlUbOxPlnn8K9vh5xwOFyTDPRvn+/kldffL8DnxjdSeJn2t+a/yP06/YyvI73/gl l8D3jmeTy/CsEJJ45QbSPwxj8K/F/wD4KU6E+gf8FNvE1/bRJAdZ8N2GqJLEcEuhaNmJ67gUU/gK /VP/AIJy+IX13/glv4StLl4Wm0bUL3TFEabTsinbYT6ttIye9fBH/BV7TPsv7Ufw61Y7BFf+DbyB OOrQygkZ743g47V8FwJKWE4+xVF/adRfjzfoejmlp5ZCS/u/lY/cTwg5l+F3hu4Lea0mlWzlnHJP lIcn0Jro3ZlZe53DB7da8y+DN++o/sm/DbUQ6XSXPhmyk83P3v3K8+9elyFWOHicKeMDH8q/EcdB 08ROL1s2vxPootOKZ/LX8W77UtU/4K7eL7i9ghtL6X4pRJti5C7bu2VCP+AgH8a/qJhXNiqM8isV GeSMnA5r+XX9qS6HhD/grR8Ub6G3z/ZnjeG+WJDsJ2i3nABxwTtPPbNff8n/AAViSLwjJLafBK9m vokJDzeIIzEVUZ3EgE5wD0Br+hfEHhXMc6wOWzwFLmUYd0rXUbbtdj5fKsZSoVKyqStr/mfsg+51 zlTgcsTt/P1r+fD9u+1bSf8AgtLY3MMTxzTx+H75AQDuYXRTcPbjGDX7v/D3xRd+Nvgj4Y8Wahpc Oi3msabFeHT0uhcLb+YoYDzMANwfQV+J3/BU/Tl0b9sr4c+JYoVEl14ZJLqjIWNteROfn5zgEngZ WviPCPmo8Ryw0lrKE4/NWfTToz0M8s8IpLZNM/ZD4ofDDw18ZP2dNY8B+MNJs7ux1KxIR7mASG0n 2ZSdBwQ6NggjB4r+ev8AZH1Z/hP/AMFfvAunyTyX0cfiO98NXk8ClBPuMkHmhecKXhVivUZ9q/pL 8PXFvqvwu0O6+S5gudLgkz5mQ6tEp4PU9evWv5bJLhNE/wCClcNzpVhPpU1h8YS8Vok7ZiRdSCiE c99xOc4IfHSvd8JufE4HM8BUl7jjt0TkpJv8vuObO0oVaNVb3/yP6uFBB25+bPJ5qIlRcLGp3swO 0YPahW8xMmHy2I5XOcd6cWTyiR2PUnivwm8X11Po0j5J/bq0p9W/4JRfGWBAA9vowu2IyeIpFc/o K/MH/glfrl1a/t2+N9EjSJ7K/wDB5lmfdgjybnKYHf8A1hr9kP2hNIXxJ+wt8WNFlujp8V54UvY2 uV2nywYWOeeMexr8Rv8Aglmxj/4KP3q5fbJ4AuDjA2cSwHnPPfj9a/b+DKkanA+aUn9lt/hG34xP ncwi45jRf9df8z9EP+CnHiSLSv8AgmbfaCJGE/iLxBY2UWDydsolfH/AU6V4L/wSc8PW8Ph740+K p9Pliv21Gy003Mv8KpD5pi2n7uGlJPrkeler/wDBUm4jX9hPwjbzKEkl8cWawTknCEI5JOO2K0f+ CYOjxWv7BviXUlBefU/G988s4J/e+XtjBPrwoHPpWNCusP4cTtvUqWfnrH9I/eVNc2bK/wBlf1+Z +iuo2Fvq3hy+067igksrm2e3mjdA6ujqVYEdwQTxX8zlz4P1D9lL/gsN4Z0O+dp9O8O+MrK6s7tx 5Yn0+5cokmMnAVZWQ8/8szwMgV/TdwmSVyBgfh61+BP/AAVS8PWOj/tq+EfFVmXjvNZ8JEzhjkGS znBRsfRyPQ1y+DuPnLMq2Xzf7uvBprzS3+5yKz2klTjVW8X/AF+J+/SSeagePaUPzBlbqDyD+tAY F1Z+QT65rlfA+oHUvg14P1FTGrXeh2k2FOAd0KE4FdXjDqxCsem0Dp71+VVfck4N7aHtRd1cXzGO 7oOOMt1oMqK65OOeoFLv2xElVOCMA9sU1ShZjg55yVHSsXLTUeg7KsQAGDHJRi3H596euPKIztcj g9qiHl7RnlhzjHelABXG6QA8g4xWkHfqIeBv2gogLHaw3cEd6+Yv2TXktf2Xdd8OTB1fw9471/Ss O+fkTUZmjI5OF2OuB2HFfT6Lz98qARlgOv8AhXy1+yfBp/8Awpz4l32k2drBpN78Udfnt5Ir77R5 +L2RXkb+4S6v8vp7V9DhbSyzEeUqb+fvr8mzmn/Gi/X9DK/a5uzpOmfAjWba3hu9RsPi1pBtondF OJWe3kKliMERyueP617j8RdHi8RfBDxjoXlPKl/pFzbbVRWZi0TAAbsrnPqMV85/tn28954c+Aul 2eG1O9+L+jR2qrFHJ9yXznba4wSqRueoIxnkivra+jZ4p4Igys6sFbb0JGBxWmNqeywGBqK105v7 pJr5Xv8AiFJJ1KkfQ/mu/YE1v/hDv+Cofgiw1dZ7K5u4L/RJY1UlhLtGEbbnvA2T0GPpTv2yLC4H /BZXx5HqMSwQXeu6O6P5W8NCywKGCk/NyH46HFeffDfU9R8D/wDBWfwzcTSPb6nYfFOSzupNoQqZ LuaGQHPABEn68dq9N/4KB2etaJ/wU68a6vPZzaW1zY2N/o9yG3pcpCpxKuRxh1wV7ED+8K/qX2V+ KYVo2/eUGvunF6feu58YpP6jyvpL9D+jzS1MOjWCqQVW3jXCgKCAoA46fhX5Q/8ABV9ZpPgz8HpF jU2w8QXambcN6sbVyF+hGT+Ffp94E1mLX/gz4R1mGY3Ud/o9rcLMgG2TfErFvYE1+O3/AAVd8Vw3 nxD+F/giK7hYWGkX+rX1tu+dWcLFFkZ43AyYOO1fzr4Z4WrLiyjH+Vzv8oyX5n12czj9Rk/T80fn h8D/ABDd+Dv25/hV4gtCFltPFdisjScbY5pBBID7FZTX9RfxINjF+zl43nv5tRg0+PQruSZrKQrO iCFidhHO70r+X741+FvEnw4+N2gPrOftknhfSNYsy67GeMIHVeABlTHtzyeRnNfvd8dfjz4Y8L/8 Er7nx5/aKLL4l8LLbaDEGIkuri5twERM9xkk57A1+j+K2X1MfjMrr4dc3O+W616xa/N9O55WRVVT pVoS0tr+Z/O38LbX7Z+0H8N9NiBzeeJ9LjjzycNeREE477eTjvmv6t/iN5kX7OnjYRx5YeH7sKMj tAwr+XX9nfQLvxF+2x8G9GtUMsr+LNP/ANUfmxA3nMw9sRE/Sv6jvH8jW/wP8YTQW32uaPRbt47c j/WkRP8AKe3NcfjfVvmeAgt1d/e4/wCRXDcf3FVn8uH7Ovwu0f4y/tKeG/hvqviG/wDDL6zp1wun XdpbiXN3HEHjVwQRsPzbj144NdNrWnfHH9j79qP7GdRvfBnjK0gWW3vLC432eq2+87T0xLAzDBVg GUkjjIJ6H9hTUNG0j/gpV8H7jVsvHJPc29tMshURXEsDeWTg8jh1weM4r9Xv+Cjfwqg8YfsIN46j tdNfxF4LnW/E5XEptXIS4iVgDwVO7B4yoPB5r9B4h4r+pcS0MsxEVKhXilqlpJykl6p6Jp+q8/Jw mCc8HKvB2lF/hZHyP+27410j9oP/AIJ3fAX48aDA/mw6pPpOtW5hKtY3UsJEkZJ7CWNQMcHINfLP 7JP7ND/tN/FzXNAfxTJ4T0nRLGG91C6jshcySrI7KsaBjhG+XO4hh7Ck8DeMtR1X/glZ8efheW+1 f2JrOmeKNMhMg/1f2hY7ooD0Vdu8/Wvq7/glEkS/tMfFsM5WVPDloEG3II+0Sg/SscTUxHD3DONp 4aXK6EnyPe0ZNSW66KdtuhUFDF42m5/bWvqk0/yP0U/Zk/Y+8M/syeLfF2uaH4y17xZPr1nb2zf2 jbQxeQsTO2R5YGSd/fpjivsRgmz5zjHUY7+1MEig4BjBC5BB7U8PuDEeR7FGzn3r+Uc1zTF5liXi cVPnm7XenRWWyXQ+1o4eFCChBWSOC+ImjX2v/BjxboenOxvNQ0a5t4HQgku8TKBg+pIFfzcfsaT6 l4c/4Kc+BPDl7p8iXd42oaBq9m8wVlUW7rMpPIO1oenfPFf08TMVUEKH8s7iMkcDnFfzdTWx+EP/ AAcCTlTIWs/ie84abIzFfozk+/Epx3OMV+veEmL9pgczwdld0+Zfc1+bR4eewtWoVOzt+KZ8oXng bU734l+PNI8JabLfJ4ckv7l4I2JkWyt7l0ZwG5bYNpI4OK++f+CfP7QH/CJeMfEPwU8R3BGheMYZ X0KQktHbaj5D5j5O1UmUZHQFwecsKxv2WrrRLj/gu3ry6Otzf+HtY1jxDEouk2NJFIQX3I3ONwYb TzjFeH/tPfBLWf2cf2xbmw0yW7s9GnuP7a8IajEnllYvN3bFxwrwOQv0K8YzX7LmuIwucznkuJ0l OnGpFve93+MWk+7TfmeBh1PDNYiOqTaf9eZ9bf8ABLbUpND/AGwPin4RvFmivLrQw5RiFSJ7a9nR gy5xn5gBjOMY6V9b/wDBS74bN4x/YUh8Y2NnLdan4M1NL2Z4nHy2cn7u4Yr/ABAK249xtzX5QfsZ eNF0r/gqn8Ndf1nXdRshqerXNvqF0jqvny3MbEJLxyjyDJwPvY6V/S14j0Sz8TfDnWfDuqQC703V LCWzuImQYZZEKn271+SeIuIq5JxjhsyWt1GT+XuyX3L8T3srhHE5dKj6r9UfyX/DPS08WftI/Dzw xqiNf2t74i07TbmOeRnH2fzwWjGc4XapAA4APFfs3/wVM0OU/sYfDe6slX7JpXi+OFxnGxHtpYlA HfGV5r8pvhJ8PdUg/wCCm/gX4dxyyw6tpvxAjs5G3AOPsU7uzAjj/Vxrz/tGv2N/4KbXsVv/AME7 LO3m8p5bzxfYpEcbmUqxcnPbhTX3XGGMf+tmTqm7r3nbylZX+6/3HlYCN8DiHLf/ACMv/glZrKX/ AOw74v0fzX83TfGc/wAp/hEsUci4+uTXl3/BWSzj+wfBG6ks3kk+2X8Qu2XKBGiUmMn1OAcegNS/ 8En9ct/+FcfGLw+WiNzDq9nfGPd8xR7cR5+mUNbn/BVgxn4D/CANKqTDxPcFY2fll+xyZb2xwPxr 4mjTdDxMaXWT/wDJqbf6noyfPk69PyZ9jfsQa5beIf8Aglh8GbuG7N6troSWM0jyhyksDGNkPpgg jHXjmvq5gAjLkbQueBX5vf8ABMLxfour/wDBOW28G2d4ZNY8Na5ex3sJByizTNPE3I5DK4x9K/Rv aoiYD7ozg92/z7V+WcZ4R4bPcZTatapJq/ZttP5pns4Cop4am/JfkfzFft66ZHYf8FTvjPJLDsuL y9sbqBo5S4Km0CncvqSvT296/S/9m/8AYl/Zr8e/sC/CnxT4o+HMeqa/rfhyC71O+bVJ0eWWVdzs CrDbnJwBjb0HSvzg/wCCgFgbH/grD8THkZ3juJdOnXexPytb4xz0HyngcV+z/wCwj4gh13/glh8H bqCWaUWWmPYMz4GHgkaMqMdQMcewr9v41zTMMJwhl1fC1ZQdqabi2v8Al3otH5HzuXUKVXH1Yzin vv6n1ppGj6foPhjTNE0qBoNLsLVLazhDk+XEihVXJ5OAOpr8gP8AgrHa/aNC+DEqvbCRrjUrdQfv jfB1z6Z/Wv2GmvI1IDX8UJfhAWUc+gz1+lflT/wVZtFX9nT4T6k1vOzweLXjW6QZjjV7WTcrD1Yg AV+TeGFSa4pw05O7k5a+bjI9zOIf7DNen5o+r/gR8U9Jg/4JDeBfiVfziOz0vwKs96xfzCj20JV1 J6nla/AP4HaPqPxa/wCCjfw5B0+W8n13xuur3lrBziPz3vJST/dX5cn2A712eqftQ30v/BI3wR+z noxuotRN3cDxHe7XiBtFuDJBbRspG8OCu/2BUjmvr3/gmd8Bru++J+q/HrVYpBoulCXSvDJabY91 cn5bqYqBgooHljnkhuOAa/Y8LlceE8uzXMK/uupKSh6Xah97d/RX2PBqV/rtWhSjrZK/4X+6x+4K uS7YJ25JGeMUm47wvOGPUDmoshlG0HIPfijcrOdytGxGDlepr+V09D7SyRz3i/SrPW/hZ4l0e/hE 1peaZcQTRtzlWiYEYr+c79gPXIvCH/BVjwRaXV7FbW11FqOjCS4IUSEjEadcbmMIwPUGv6Ptej87 wdrEJD4lsZlLR4yMxt0zX8r/AOzPc2Ph3/go98H/ALRJNLZWvjWOAOYtzNmSaJCV+uM+lfufhRR+ s5Jm9Fu6cFp6xn/kfNZ1LlxNCXn+qP2g/wCCnlhHc/8ABN62vWj3Gx8XafKj4HylnMZHPTg9q5H/ AIJX+J4L/wDZJ+IHhj7R/puleLpLjyDNuYRXEaSKwXspJIPqQa+kv20vh9cfEr/gmb8VdBtDJPf2 un/2pZwwcGaa0YTKmPfYRivyo/4JifFPRfB/7ZfiXwhrF3baZB410iFbCa4cIHu4GZkhDHozxyHA 6HYaWRYVZj4e4qjDWdKfNb/wF/lzfcViJulmsG9pK35/8A/oLMiCMqTznAXGf1r8JP8AgrTqdtP+ 0L8LLGO5t5Lmx8M6g81umPMiE0kSKX9jg4+hr9x9a1Ky0fw3d6nq13aaZp9rEZZ7i5kEccaAZJZj xjFfzZ/tB+NNK/am/wCCs+mt4PtH1DQr6/07w7pkqKc6hbxz75bja2MAgyYHdUB/iFeb4M5fOWdP GNfu6UZNvpqrb+l38jXiCaWG5FvJo/oq+Glkum/ADwJpiXC3ItfD1nEHZOTiFMGu7JbaxyFGcjPS vl/S/wBqf9nez+LNl8L4fib4XfxXFONMS0WYhVmj/d+UX+6GyMYz14r6ajZcK8Z6jKhua/NcyweJ oV28RTcOa7XMrX81dHr0mmrJ7FhTI0o4LuOrbc08FcZ3sD2z1/8A1VCCC2VOM4J25GPrUxjJi3Ft w3Y54P0zXC7FMaAQ65XeRwvf8afzgsVRskjjvikDYUEBfX5TTiVyWVW5PbFa2vq0QxysWlycDDDO T15r5H/Y9lsYvhZ8YtDtD/pWl/FzxBHdRsArI0t206qUAyo2SKRnOQQehFfW2SI2GJC4PAzzmvhr 9h5Lz/hBPj/fanc3c+tzfF3WGvorpk82Jlk2xhlVQUJjCHnqCCOCK+ny2knleMbdrOn993+jZx1f 49P5/oWP2ytVj0H4ofsoavfvcw6HafFuD7ZPFGWETyWs8MRYjoC0gX/gVfYs11ZBQGurVDySplUH r65/H2ryv4//AAH0D9oL4X6R4R8R+JfFnhzTLHW4NULaFcJDJO8JyqMzKSBnkMpDKQCDxXjzfsCf s4PYww3mkeOr66jB8y+l8caj9onY5y8jLKAWP0rtr/2Vicuw9OvVlCpT5k1GHNo5XT1lDv5kQlWh Vk4wunbrbp8z8A/ilqNn4e/4KV+PfEFrcPPpmn/EeTUVuoU3jZFeRys64yGwFbHrivvb/gpA3w/8 bfDL4Z/Evwr418I6hq1rbmC6sU1hDey2lxsaJhBknCygFhwVGe3Ffey/8E6P2RhZ3MP/AArF5BPG iM7a3dGRdvdW3/KTjkjk817z4Y/Z++C3g2PTU8LfC7wNpL2Fu8NtNHo8RkVHADguRlt2BknJNfo+ Z+JeUvEYPFYaNRzoJppqKUk4pWb5nbVdnY8ihlNdwqQnZKWu7019D8Bv2fP28Pin8Dfg1/wga6Jo /wAQvC9uf+JRHqV3MsmnrklokkRW3x5xtU428gEjGPE9V8U+Lf2jP2xLW+8Z6ha3PijxVq9nZKsr Jb29rbebyg3kbIo4/MwTknnuQK/oR8V/sO/st+M/Ef8Aa2r/AAf8PWl885nlfSnksUlYgg7liYA5 zk8deauaD+xX+y94f0JtOtvgv4Lvbf7SLj/iZW322QsAVGWkJJUAn5c45roo+J/CuGrVcZh8JOFe pu7R3/8AA++rta/UcsrzCcVSnNOK8/8Agfnc+Kf26P2eIfih4F8MfEL4ea34b1fxB4X0YafeaLDq kIkvrNSGDxEvjzEKkhejKT3xX4y694v8Z6l4e0fwnrvijVLrSdFgW0sNNv8AUMQ2MakkIsROFwT1 ILDpnFf1EXH7If7MVxERJ8BfheqtzmLQ40OfYqBitCz/AGYf2ftOvknsPg78ObYphxt0OJn3rgK2 SOoAxmvM4Z8VsBlWCjhq0J1uRvlbhGLV+nxy7uz000NMZk1atUc4NRvvq3f8Efjf/wAE+I/gf4L8 aa58X/in8S/BOgatpKtZ+GNOvtUSOdSVzc3ZjySQwARAR0UnvX6ieMf2qPglrHwZ8Qw+HPHN9qs9 5p1za2U+ieH7y+LTGJh8ojiO4jPSvpPTfh94K0Xzf7H8J+HdOjkcSNHb6XCoLdMnC9cVpatc2Gie Eru7JsbJYoJZUDhIgxVC2B06gV8TxLxZgc6zT65UpVG7pJc8Ukl0tyS66+rZ6mCwdXD0fZpr7nv9 6P5U/hB4Y+L+gfE/wD418KfCvx3rDaPq0N7bND4euXguWjkPmJ5hQJ90ydxgnrxX7VfG748af8SP 2SPHHgjTPhR8fE1LW9Iks1ST4dXxikaVOAWKAKu7jceBXHXP7Z+seMv+CTOvfELwbq/hXwh8TLLx BBp+qW1iFn/sezl1AW4vWhbGFMeWBb5cg88Gv0002YyeH9Phkv4L+7+yRySOrBWlJQZfaDwCecdK +x444rqTxdDF43Bck6U5RilU1vDlk7+5ZrVWs+/Sxw5bgOSnKnTqXUknt3v5n8pmj+DPit8NP+Eo l8R/DT4g6Jaah4Yu9Hv57vw3cBNkyJkiQoV4ZM7s8Ve+BXx1+KP7PfiXUvEnw8hsPtmradHbXMmo 6NPdRSxxsSChUrj5icsCc8V/Sx8MI/ipPpPjfSfjDb6PeS23iO4j0K+sY9sOo6awV4XMZJ2sNxjY HrsJ6GvR4dC0OC2S3Gj6bBbgYSL7GgVR7DHA+lehmHjLh5RqYfF4GNRStflneMlut4f8N6nLR4fq R5Z06trbaa/mfzt33/BRj9qLVfCc8EPjjwhpKpOge5t9Ghhu8E52hZJDlOxIXI9RX6xfs7/th/DT xb+yZ4H1f4nfFz4d6V4+uLIHV7G41aCKZJs4JMYOUByDt6jPNfWEvgvwZOXaXwp4Xn3A58zTIiTn 6rRZ+GfB1pdGGy8M+FLW4iXA8nS4FeNT6jbnB/Wvis/4p4ezLCqlRy72LTveLjfbZvl2PUwuExlK d51ebTrc8iuf2rv2bjqr2Ft8ZvBN5qKkL9ns7/7Q+T2UICT17e1fg/8Atn+JrbxD/wAFE/GHxA8J L4g+xywWV5pN/JolxbJcSWoXzJF3op2oQuX6ZPWv6VU0bw9aqjRaTo9rN/C8NnGhH0woxUV3YaVq CNLPDZaiyKVQyRrIVHcYI4Hr61jwhxfl+Q4yWIo4ec+aPK+aa7p9Kfl1ew8wwNXFU1FySs77P/Pz P5vdJ8f6npf/AAWbHxH8I+EvFGoxQ65b31xpWn6Dci7a2ms4o7p/s5TeASd4LAbsZGc8/oZ+0/4h 8B/tE/s9al4Vh+FPx5fxvp0T3nhm9HgG7g+zXG3Cq0siqjRsDtZS2CPQjI/QrxRqnhDwH4I8QePt chs9I0/TbFrjVdSMaBvJjUnDPgEgDgD8BXmHwY/aZ+Hfxs1Q6boVj4s8O6sbIahbWPiTSpbJ76z3 bftVsWAWaMEgEoTtLLnG4Z9/MOMJY6pQzOhgZr6slHnU9FbpL3HdPW/k9dzno5d7OM6MqitNt2t+ WqP57fBvwD+PHh744eDdTuPg38RN1hrNnqDkaI8kaiGZJH+YEgjAbCk5PFf0DJ+0JqgsLfz/ANn3 47QCfb5LpokLkgj7xVZiVxjowBr6QjQJKUVZzGz4zng/T/OaldY0nZm2nJAw4I/XPWvB4s8QYcQS pPE4VLkTtaT628vI3wGVywiajO9+6/4J+MUnhDxBp/8AwWt0r9oKw+CHxnfwPNbNdSwReFVtpYb9 4WhJ8sScqRjLHBJOT7emfto6345+O/7J2ieEfh58DfjBJdv4lSa5lvtBEBiW33BlKl88tgBuFYcg kV+rA3bcZuFG75zvJU/ietBWIXRTzgz7hjLEYHtWf/EQObG4bFzw954eKjH3nayva+m+u+lxvLH7 OdNSsptt6f8ABPwu/Yx8FfHj9nD47+Jde8VfAf4tahoWr6Kls8em6dbNKZYnZ1yGm4X5jyD17Yr0 D9tHRfi3+054e8Ejwb+zl8ZtE1Lw5dzyXcmtixhikhliIIRVuW3OGAPTpkZr7K/aC/ah0/4H/tO/ Bzwtf6v4d03wtrl7dN4t1O8kaWXTrdIsxYRWyjO5UBm4PpzX0Z8Lvih4J+MnwktfHHw/1yPXPDlx O8KXDQtGVkRtrqVYAg5/pXuY7i/MqWNo8QVcCk5KyknLl+1Gzs92k7JvZJmFPLqboywqqXtv37/5 bH5LfsV+Gf2k/wBm3xJ49h1/9nL4keJtE121t5YoNOurBHhmQMN2ZLgKQV2ggcgiv0MPx5+J39mh rj9lD43CZtoMcOo6SwyQeQTdgcY59yKP2cviv4s+IZ+NGmeNzpbar4P+Id5otsbW1MO+1VUkhZ1y fm2vjIPOM+1XPCXxb1/xJ/wUt+KPwie3sV8K+GPDOn39vOsbC4e4uGk37jnGzCjAwCD3OeOHiHH1 sxzDEVsVg4OpCKlJqU0rLlSa97+8uhpg6ao0YwhU0e2mvc/F79qb4bfGz4y/t+a54p0f4JfFLSB4 itIZrGw1W1gMwW2XypMMkpjABZSBuyckgY5rypPhN+1/4U8KQ+HbTwX8d9M0S1nM0NhpjzpbxSPk s6iCTAJyc9jnnmv6i2iikw8wDFeEaTll47f/AFqhje3lkeCO4ErI210V87D2GAeM+9ezhPGavRw1 LDrBQcIJKzbe2i79PnvrrY5JZDecp+0ab7I/lsu/h/8AtW2cEV9N4c+PcGoQPHc6bDLDqNyzSBwV dRvZV2kAkOOfwr9Av2vvEniv44fsJ/DjQfD/AMPvi1qnjG01qC81uzXwhewwyGGIpMVeRB/EeDjD HkZr9kyBJHiF0dQcABwxB9ODT0TfbbQJRgEN8zAVwY7xUjiMThsS8FFSottWlbdWafu7dfXqbUsn nCnOHtLqWmq/4J/NF8Ef2Q/E2ufGNrj4teBvi/4T8F2yJdfZtL8PPcXl6pYkQK4b90MD5nI3YOBg 1+4Pgnxr4O+Hnwx0nwd4K+EPxf0bQNKgWK10628JSBUViOclsM2TljkknPevpXyUjUZLIQckb92R /wDWr5z8FftLeAdW8afFLQ/FesaF4BvfB/imTSPM1PWY0W9jEMcqzKSRgEPgjtivO4l4ux/FF51a LcKdnyxlZK+l7ct27vfW1+hvgsvp4PSL1fVp379zuIfi1aSS7W8A/FW0lecwiOTwpKegzu4JG3Hf PXjrxVz/AIWhCunxXMXgr4nTW72/2k48OuGCDruUsGD/APTPG8+lel2k8N3p1tPY3RuraRFkgeGT IdDyCDnkEHIPepGB2IRLOCSSc9R/n1r899phL29m/wDwL/7U9R+07r7v+CfO/jD402t98G/Eq+FN O+Idl4jbSrr+zXl8E3pMcyxkr+7dBu56Kep6V/N/4W8B/E7QfjF8JvHXiLwP4ygtdT8aWb2M8+lv Gb65julkljRMBi5PmHG0Dg44Ff1lMrSIc5Dfw7sn+dZ0+m2d5cQNPbQzS28vm28kkIYQuMjcvHBw SMjmvvuD/ECjkFKtSpYXmVTe8lfZ6XUFpr+fVnlZjlcsXKMuezj5f8E5eHXrLVfCLXb6br/2e5s2 le3uNKljl2FjGyGMjduySNvXHPSvwU/aa/Y38YeDvjVq/jD4I/Drx1J8Odn2426WhWbRJVbJSIeZ 5rpuy6FAWXoO1f0SGIhsFztJ4O+pJI224ba2CMEknivH4S42xPD+JlVw8Lxno4t6NfJLVa2f4NHR j8BDFxSk7NbNL/g7H8pt9L+1F8Q9ITwRfJ8d/HNlGRIdIurG+nUbRgNIjKu4DGPnJGexNfbX7K37 NPxH+Dvx2074ifET4HePPEmsCyZ/DUOkajZtDYTyQuJJbkvKrLLtbYqYIUluSTx+64t1DK3yqpP8 C7f5dTT44EjjIO7LEgZQYPtn1r7DNfF/E4rCSwuHwcacJpqVm7u+9uXlt56arQ86jkijUVSpUcmu /wDw7P5dNY/ZL/af1Dxtqmqw/Bb4h20dxqUt1Gu2GR0DXLTKSROCWA6nPXv3r93NJ+OfxBh8M6ZY 6Z+y98ddduLe0hiklkGnWSFxGAxHnXQOMjrjvX1gkKlhuXkAqM9vTFTlSzlWHzZ7c8e1ePxH4g1c 9jSji8LFqne2slvZO+qb27nTg8s+q83JP4vI+Z/+FtfHBdLmmi/ZZ8Um4Rlxbz+LtODyAjOV/eEc dCCRjjrVdvjx8TrO4SLVP2SfjcszscNp9/pN1Fu7fMLsYHuQK+oRgz/cDEnv2oIw4GMHPQ96+Yjj sI98JD/wKp/8mzscKt/j/D/hj5Un/aD+Jy28klr+yL8eJpFBCiSbSEUkDIyfthOPcVzdp+0Z8cwi pf8A7GnxeiuNnmP9m1bTpF2ZOMEzjLYx8nWvtJhvXcFU4Jzzx9KXgoCGAbcenFdEMbgOWzwcfXnn /wDJGbhWv8f4I+Cbv4+/tea9PqFz4H/Y+u7bSImSO2l8VeKYLO7di21mMKFxsXqfm5HTNJ+xn4U+ PGjfEz9oTxD8Z/AX/CBp4q8Rx6nZ20GowzW0k4jWKV4kXL7SI0O9iAc/dGOfvny0wGyGbrmh8fZX HzMWGBx0r0ZZ5S+pVcPQwlOCnZNpzctGnvKbW67GX1abqRlKo3bpZfoiJ5WDbXJYD0HFRmUNLjBP tjjNTvk5IAyDwV64qs8b5Vlxu/Gvja1evfY9CCQFwJQArbSOfaniVVbA3Z7YqEQSOxbAGOQDUYhl 2OUZOeCRndXIsVUWtjW0WWxtfgEDHvnNSKSPl4OT1FZKQTqdwGWA4OeTUyreB/4Mg9z2q/rcm7OI nBdy6SuDlsY7nimMu6RmGSSOTimL5u9DJ5eB71IufvMBtJI+greNSFT1JasIUGzO0YPYCvCf2gvg p4J+NfwQuNI8aadqd/Hpcc99py6fqEtpKswhcAZjYFlIPKng174WJbG5R6YPWmzWyy28kciCVXUq yMOCCMEflXTgq9fCV4V6EmpRd01v/VjKpGM4uMup+JH7Ox+Cek/8EIfGdt4ksfDuneOvE+m6vYat Zwhf7a1eS3kl8mNUOZGZAMqgGF5wK4/4SaF8T/gz8aP2SPjH4i8beJ7zWvijK2k+IbXWZneCO2dB 9lhCHBRwqqQD0YnHU1+rvgb9kf8AZ6+HHxnufH/hD4X6Hp3iqSRpILxmaYWjMpVjAjkrEWDMDtHQ kd69i134feD/ABP4i0LVvEHhjRNa1PRZWn0qa9tFlNjIRgvECCEfBI3DkCv1XF8d4RV8R7OE5067 lKXOo3XNFpQiruyT5Xe9/dS5dDxaeAqqELtRcbLTrZ7v8dPM/JG7/aN+Kvhf/gm1+0VqWmeKL4fE 7w78XZtDtLzVHimNtDcXqhFj5I2rG+MsMAg8cVta98RP2jf2ZPF134c8R+P/APhbGn+LfAl7rPhn UdagVJrXWLeESPaxlVCspB3Kp6hSRjBr9IvHPwH+FfxD8D6h4b8SeDtPOm3+sW+r34soxaveXMDq 6PK6AF/ugHd94cHitrxr8L/A/jfSNJPivwrpmvf2HL9p0bzY8vaSquAYj2JHyY6EHHevOhxVk6kl LBLknKTmuWN/hhy8r0aSkpO2is33Nnh8VbSpqkra6bu9/lb5n5OeBPjp8U9D/a5/Z78NyftD33xU 0Dxv4cfUvFrPZ2csWjuYC/HlqvkxoSGJck4GO9dT8DrrXPgx/wAFGofDfxut73xb8QviDd3cnhP4 iaf4hkuLLUISNyQPYhsQrtUH7pC9mOSa4H4geH/Ceu+N/htYfCr9lD4n/Bj4s/8ACWBNQgt/DJis dR06ZmhvUlu4iYzH5TO4+YBSB7Z/QD4J/sTfBr4J/Ea38Y6NH4l8UeL7OJ7bS9S8Qak10dMtjnbB bp91FRTsDAbto68nP1Ge4zK8JgpuVPklVhKPLGEYybUpNO8HyqOsU/iU0tro5sO605qz5rNO97qz tffW+/a3zPhrSf28/Efwx0C38OeOLuz8WeLn+LOoad4iGpL5SaFpK3JRXVUXJCqQV3fwjk85rxzW f2mvjDp/7TnxX8Jfs0S3ut+CvF3iaXWdA1ZbN7qdokgijuzp4uHWMxiUNkAsAcgLX7XXvwO+Ed/4 s8V69ffDXwTfaz4mtxbeILyfSY3fUYgAAkuRhgcAE98DPSuX+JH7Lvwa+KPhHQNF8TeDbW2g0FSN Cm0WRtPudMBwWSGWEqyK2BkdDivHwHF3DVGs5PAv3/iTs430knyaX5ZKy1Xutt6uxrUw2NlH+ItN u/Z6+e/qfkV468d/FjQv+CeHxutPjNr3inU9I8VJaad4T0Xxdc2LaxbzuQZbuSOAjyoAzABMFhtz gCvWY/2zvEP/AAo/4QweBPhPqHg/U7qe08P6Z49+I9pHDozQtEDJslibID7FwV+U8dcYr7k8N/sQ fs5+FrLVzYfD+31PW9Qt5on1vXLybUL5fNQoxWWViVIHAI5Az615h+yj8FPiDZfsz+Ofgd+0J4F0 PVvh/wCHtbew8LjVNl0dSs97SKxHIEagptPDZyD0r0a/EXD+Kwc6vsLqnNNx0p3UoqDcYKT5rcq5 k2r3baS2xVHFwqpOWrVv5tnfV20303t5nzfoF98UPGH/AAUi1n4b3fx0tPHkXjPwZeW/jiLwMstv p/hWRI0FrNC5kfy5ssfnUqWGMg8Y5/wH8SP207n4YfE3Tz8U/BFpcfB2WW11qzvNDNxqWpR20W+N y27DrMn8Rw2fQjNfrf4D+Efw5+GOjT2Hw/8ABPhvwhaTsWnTS7BIfNPXLEDJ/Ok0v4SeAtE+LnjP x3pvh21tPE/i23ht/EN4Mt9tjiUqgZCdvRiDgcjrmvnavG+BfPH6mpJRhyuUIayi7NtLSN4O2nNb lje+rOtYOumn7RrV3s3t09dfTdn4tXvx5+LumfHj9nXVtH/aTtPiH458batbzeJfCenXMA0XSred 12WwUDcMIzglmzuUHHavQtR/aa/aZ+IP7VXjzwNpnxH+C/7P+i+H/EFxpjW3iQlNRSNPuTqsv+uE gG9SAq4bgnqdv496b4Ms/hV8Qvg14Q/ZJ8XeBfihBq0V14R1nwb4O82yv7qGVXtrpLqJNqJ8q71c gAZB45r760v4LeEPjD8EPAHiD4//AAa8Fah8RW0K3/tW31TT47iazn2DzIvNHJwwGeSK+nzTM8ow 2Ho4mtglrzRTcabfSUZKCfLKNnyp3uratt2OSksRKThGrfru/Rq9rp31tY/Or4pQeCh4g/Y/+Ini 3x78OfjT4gl8Zy6V4n8dwWsEVtqdvGkp8qYr8pjhJH3uhGeK/Svwd8YvgzqfgUz+D/GHg+28PQ68 2g28kbpb20l8MH7PDwFdiCD8tb2p/s8fBjWfg3pXgHUfhf4HuvBelXBudO0eTSI/s1pKd250UdGO 5snqcnOaq3f7OHwYvdA8K6NcfDfwyui+GbprnQNKjtQllZzkg+csQwvmZ53HnrXw+bZ7luY4elSq +0Xs3K1lG3K5OS91NK6uo2VlFbNpJHfh6VSjJySTvbq+yW9vn5n4yeOfjF8Rvhr/AMFKv2qdR+Hf xX0v4e2mkavFrR8P65bxLa+Ip47aNHgw+HDNgBNpAYEH3r07xh8evFGh/tPeMfjF4T0NdH1Dxp+z dFr0bXRA+z3lu5IcK2CxTzenfAxmv1w8U/CH4a+OvEWmar40+HfgvxRqdgwa0utQ0uKaWAjoVZhm oL/4KfDHVPideeMdQ8E+Hb/xHc6N/YtxeXVkshexzn7PtbKiP/ZAxX0P+vWTzjT9rg3zKChK1ves o2Ttbmu43u9VtqtTmeBxCb5Zre68t/u32+Z+IXiX4yeMvhrqL6h8J/jr8T/izq194fS3+J2uTg3+ leH7m8dUhmgiUbUlj/fYRByVAb1rR+BGsmKy/a68BaT8WfHPgHTdY8NWWs+HfF/jQTxX8tvGzR3F 3Lu+dUc/LvQAhSCCMCv2L8Y2Ph74E/smeKtX+Hnwu0u5h0XTmuLLwzounrCb5lPEKLGhJY54G018 K6Beal+0Z/wU9+GHj3RPgH8RfCfhGy8JX2k/EK68a6ObG1uLa4X91bKsgxOVdWBVRj5gSeOffwHE dDMMFXlHC8lOKu6j9nq6bjUipR5Ur6csVqtVGzepzVKFSnUjepd9ry66b3+b6+h418HfjZrnwnj8 SfAPRtQ8G+K/Emu+GL3U7Px54O8Vzal5d1FbFknuknDeSQFGMEgnGRya8Rf9rX47+KfhknxHi+In xMtvGulpBO2h6Loiw6DZ6dCEaS5vJ5UPnPKMn92c5YADiv2D+JP7PmhaF+xH8V/CnwF8CeEfB/in WtBuksl0zTorYyzvHt2h8fKWAx6CvJ/2HfAmo33/AATo1H4afFz4cavYQ2WsXmmSaX4p0vAu7Fm3 xRkNkSIqsEyOMr1PWsafEeRywtbM/qinLngpKXLztNe9LlfMlF6JRT3WjV2i5U8TGUaKqW0ff81a 767fJngul/tHftGa9478C+G9cvfgn47vPF0kK6h8PfClrPc6jY6bO22ea5uklKQeXGQxZhhm+Uc4 rK+DPwe/Zl0b9or9oXSvi54R8BrZaV8RrPRPC9t4gnNzcR+fbw+VChZizq7OCM55JzX6m+B/hF8N PhlpNxY/D3wF4V8GW07bp10nT0haQnruYfMeg6ntXOXf7Pfwavv2mY/jFe+AdDu/iTHGqJrM0RZw yrsV9hOzzAvG/G7HevlpcY4OCrUsNCVCE4707Rk5KSa05rJWTje8pa63Wi6nhKs+V1LSafX09Pna yR8OfHn47aL4z/aB8E/Bbwf8YLT4W/C7+0bnRvGvinTCbae1vLdFMemRTv8ALEXUnDr0KEZBFece Pfj/AB+EfHOn/s2fBL4/eHfAXh3TLL+1Na+KPjnXv7Vun3sX+zWjyEiZ+gKnoDhelfqxrnww+Hni Xw5qmla/4G8JazpmqTefqNte6TFIlzLt2+ZJkfM+ABuPOBiuZ0X9n74HeG7NIdB+EHw602GNzJGs GgQDax6kEr1rDAcRZNSo04yw8moL4WoSTk/+Xkm0uZq9lFpxsk/I0qUcS27SSv5vRdkv1PyA+E/x d/ak/aC/a40j4e+GfjDqHhP+zvClyL7xMmm7rbWoIZwIr+CCRFUSzZA3DKAZrFm+JX7R8X7Pfij9 orxH+0XNF4i+HXiweHE8GJCkMWqeRcCOVJkXgyS+oUkDniv2wl+E3gZ/j94f+J40FIPGOjaRNpVl eW0jQolrKys0RjXCMAVGMjjnHU1Ql+BHwhumuvtnw18KXq3PiX/hJJxdWKyg6ptVPtYDcCTaoGR6 V6746yn26tgYxhaOnJBveXOuZraasr2XL0SMJYPFNfxXfXq/lp+a6nYeH7+81fwNo2q6jp0WmXt5 aRXFxbZ8wROyBigOOcE9eK3QcHJIL+jD730q0qGPABC7TwFPAFNfa5AJQ4OQK/KPYqdRvRLt2+89 lT0SIQuSN64x90Z4x9PXNKFdGDCTPGfrVkqCu99pz0IxxSYLbgfuj7tONBrqHMQMDjcAFbrzzmpM uY85GR0Pt3qXHGFY+wUdaTB9Fxnr0zWipMnmI/lMpOCpHXnil4aUbDj3Y5/CpccKowfrRtYpnrwc gDrWqp2FzEQ7jODnp60FeAWz69eTRjkkkLg09ccdcZ6D+dUoRiNsRe27OAccGkcjysZ2+oDZxR2J K9ehxTTlEwqruz2Wok2rhYQf8fI/3z/Kkb/VH60UVzrZFsmXotI3+pX/AHqKK1huQviIB/rz9Kd/ E34fzoorCv8AGv67Gshr/wCrb/eFNb77f7xoormn8bAU/wDHxD+H862Y/v8A40UV6OB+CRjW6Cfw T/h/OpT/AKs0UV6stjmIv4G+tSP/AMeq/U/0oooX8Rf10B7iv96oI+o/36KK4afxMcdiKb+H8akP +sX/AHaKK6I/CV0RKf8AXj/c/pULfw/jRRUYr+ITEG6v9RTm/wCPpf8Ae/pRRWsvh/ryGi0n3R9P 6VU7yUUV59HZ/wBdSUB+/F/1zqz/AMsoqKK6aAPZDH+6/wDvVAfvD/dP86KKqn+o4kif8hOP8f5V Ncf8e0H++f5UUVg/45L+JFNfuR1c7RfWiiq/5eL0KmVJuv8AwM1M/wBz8KKK26Mb2Qwf6sfUVJL0 X6UUUQ+Al7ksn/HufrUUX/Huv+8KKKb3j8iVsZ8v/ITl/wBxf61Af9Wv40UV5FX+I/mdsNl8hh/1 b/7n9KkXqP8ArnRRWvRFDz/qG/3x/KnR/wCo/A/yoorZ9f66IzEX7g/4DTj/AMe5/wB2iim/if8A XQXUa3+rP4fypo+6KKK6ftx9f8hrZjh2+pqQdV/Ciis5/C/67CW5/9k= --Multipart_Sun_Nov_20_10:54:42_2011-1-- From christopher.morrow@gmail.com Sun Nov 20 21:35:54 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9E311E8096 for ; Sun, 20 Nov 2011 21:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.556 X-Spam-Level: X-Spam-Status: No, score=-103.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDk+-TVIsStH for ; Sun, 20 Nov 2011 21:35:54 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8AD11E808D for ; Sun, 20 Nov 2011 21:35:54 -0800 (PST) Received: by ggeq3 with SMTP id q3so3326150gge.31 for ; Sun, 20 Nov 2011 21:35:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4X6Zphh48ZiSoYBhSJy4B8ejuAb86xJ+CrdC6OKxDms=; b=cnh5xF6s2ewzI/UmD27gA/3cy1qH/K3vFtyGycose6nUh1itsk78Kr6kakOe4k8Mxq 9Oa0myWmNN/oq5fI5knrmXmgf+WfnTZVcFurTlU/Cueo1eu/zcc95RGlSqk3GI3UyuCD 9OQpXsBOMPbNh4ZEaLspCVGN+pDzwtbdUsTWg= MIME-Version: 1.0 Received: by 10.50.88.199 with SMTP id bi7mr13061669igb.45.1321853753556; Sun, 20 Nov 2011 21:35:53 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Sun, 20 Nov 2011 21:35:53 -0800 (PST) In-Reply-To: <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> Date: Mon, 21 Nov 2011 00:35:53 -0500 X-Google-Sender-Auth: Df3ubcfQy9sodQhrSxdzrpHO7ow Message-ID: From: Christopher Morrow To: Danny McPherson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] Route Leaks and BGP Security X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 05:35:55 -0000 On Wed, Nov 16, 2011 at 11:23 PM, Danny McPherson wrote: > > Team, > I've updated this draft based on some feedback received already. =A0Given > the discussion at the WG session, and the list discussion as of late, I'd= like > to ask that it become a WG item and used to inform the BGP Threat Model > document -- particularly with regards to what's an acceptable residual ri= sk and > what is not. =A0Once that's comprehensive it can be used to inform secure= routing > requirements documents in the working group, and then we can begin assess= ing > the feasibility of reducing various risks. "The authors believe the capability to prevent leaks should be a=09 first-order engineering objective in any secure routing architecture." So, in the simple scenario laid out, the customer is filtered by the isp's, no? and the filter data is built with something like: take irr data, meld with rpki data, create filter-lists. The rpki data gives the isps an ability to filter the customer announcements, which would stop the leaks. Is the thing you really want to outline in a draft the process to link the resource-certification data with the existing IRR data and create better prefix/as-path filters? I think one item that was asked for on the list (or perhaps in the meeting) was: How can you know a route you see is a leak? Taken another way, in the case of your example: victim - isp2 - attacker - isp1 how is the victim to know that this path isn't proper? what in the update says that? is there other data that could be used (outside of bgp) to tell the victim that the path is improper? -chris From jakob.heitz@ericsson.com Sun Nov 20 21:40:53 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A5911E809C for ; Sun, 20 Nov 2011 21:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.388 X-Spam-Level: X-Spam-Status: No, score=-6.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ig618wk1fcED for ; Sun, 20 Nov 2011 21:40:51 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 31F7111E808D for ; Sun, 20 Nov 2011 21:40:51 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pAL5eTcV026158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Nov 2011 23:40:30 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 21 Nov 2011 00:40:29 -0500 From: Jakob Heitz To: Danny McPherson , sidr wg list Date: Mon, 21 Nov 2011 00:40:27 -0500 Thread-Topic: [sidr] Route Leaks and BGP Security Thread-Index: Acyk4NHdH1ffxpnPRL+kIyR4enOKPwDKu50g Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A4704525E@EUSAACMS0701.eamcs.ericsson.se> References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> In-Reply-To: <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] Route Leaks and BGP Security X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 05:40:53 -0000 To make the route leak problem tractable, we need a definition. Here is my attempt: If a destination AS, D originates a route and announces it to provider P1, and P1 agrees to provide connectivity to D, then D trusts P1 to do the right thing with the route. If P1 has further contracted provider P2 to provide it with connectivity, then it trusts P2 to do the right thing with the routes it originates. By extension, D also trusts P2. This chain may continue. It may also branch. The result is a set of ASs that D trusts to do the right thing with the routes it originates. A source AS, S similarly has a set of ASs it trusts to do the right thing with its routes. When S sends a packet to D, that packet should traverse only ASs that S trusts OR that D trusts. If the packet traverses an AS that NEITHER S NOR D trusts, then a route leak has occurred. When a route announcement leaves the set of ASs trusted by its originator, Brian's "transit" bit turns off. -- Jakob Heitz. > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf > Of Danny McPherson > Sent: Wednesday, November 16, 2011 8:23 PM > To: sidr wg list > Subject: [sidr] Route Leaks and BGP Security >=20 >=20 > Team, > I've updated this draft based on some feedback received already. > Given the discussion at the WG session, and the list discussion as > of late, I'd like to ask that it become a WG item and used to inform > the BGP Threat Model document -- particularly with regards to what's > an acceptable residual risk and what is not. Once that's > comprehensive it can be used to inform secure routing requirements > documents in the working group, and then we can begin assessing the > feasibility of reducing various risks. >=20 > bgpsec-no-help-01> >=20 > Thanks! >=20 > -danny >=20 >=20 > Begin forwarded message: >=20 > > From: internet-drafts@ietf.org > > Date: November 16, 2011 11:01:24 PM EST > > To: i-d-announce@ietf.org > > Subject: I-D Action: > > draft-foo-sidr-simple-leak-attack-bgpsec-no-help-01.txt > > Reply-To: internet-drafts@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > Title : Route Leak Attacks Against BGPSEC > > Author(s) : Danny McPherson > > Shane Amante > > Filename : draft-foo-sidr-simple-leak-attack-bgpsec- > no-help-01.txt > > Pages : 5 > > Date : 2011-11-16 > > > > This document describes a very simple attack vector that > illustrates > > how RPKI-enabled BGPSEC machinery as currently defined can be > easily > > circumvented in order to launch a Man In The Middle (MITM) > attack via > > BGP. It is meant to serve as input to the IETF's Secure Inter- > Domain > > Routing working group during routing security requirements > > discussions and subsequent specification. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-foo-sidr-simple-leak- > attack- > > bgpsec-no-help-01.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-foo-sidr-simple-leak- > attack-b > > gpsec-no-help-01.txt > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Sun Nov 20 22:06:12 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721C821F86F6 for ; Sun, 20 Nov 2011 22:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.557 X-Spam-Level: X-Spam-Status: No, score=-103.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHQKv32e2MVP for ; Sun, 20 Nov 2011 22:06:11 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C84C721F86AA for ; Sun, 20 Nov 2011 22:06:11 -0800 (PST) Received: by ghrr14 with SMTP id r14so2931945ghr.31 for ; Sun, 20 Nov 2011 22:06:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=WOkIlM0cAO+37vCgX1+qB08rGUUQkuc1xB4GkComt/c=; b=jchzk3HvYxVjglykVreoETLmZ+0bRI4flT+QUAb1f2aYYHJBr7/1NP/hSw258EJdwz R00U1xKZzU3LtqMma/ramFRyvAmGYFI+Eamy/0UrhCzkjphSSveHCUWVHsVdQh1YpXQo zfuUHcTMYi02Amn8itcN5I5WWFfu76TNFvUiU= MIME-Version: 1.0 Received: by 10.50.88.199 with SMTP id bi7mr13139510igb.45.1321855571013; Sun, 20 Nov 2011 22:06:11 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.231.202.142 with HTTP; Sun, 20 Nov 2011 22:06:10 -0800 (PST) In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A4704525E@EUSAACMS0701.eamcs.ericsson.se> References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> <7309FCBCAE981B43ABBE69B31C8D21391A4704525E@EUSAACMS0701.eamcs.ericsson.se> Date: Mon, 21 Nov 2011 01:06:10 -0500 X-Google-Sender-Auth: VM807RuXmr7HzhJOyi9Zw40jt_o Message-ID: From: Christopher Morrow To: Jakob Heitz Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] Route Leaks and BGP Security X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 06:06:12 -0000 On Mon, Nov 21, 2011 at 12:40 AM, Jakob Heitz wrote: > To make the route leak problem tractable, we need a definition. > Here is my attempt: > danny's draft actually does a decent job of saying what a leak is (one instance of a leak at least, which is fine), it just doesn't say how you'd know that from 2 as-hops away... (today, with out bgp changes and/or external knowledge about the ASes in the AS-Path) > When S sends a packet to D, that packet should traverse > only ASs that S trusts OR that D trusts. If the packet > traverses an AS that NEITHER S NOR D trusts, then a route > leak has occurred. how is this 'trust' known? how does it translate down the chain? I don't trust AS9001 anymore than 4134 than 4366 than 3 ... I do happen to fling packets through them though :( > When a route announcement leaves the set of ASs trusted > by its originator, Brian's "transit" bit turns off. I doubt the originator trusts anyone except itself... and MAYBE it's transits. why mix two topics? :( (also, how does the route know it crossed this boundary and a bit needs flipping?) -chris From jakob.heitz@ericsson.com Sun Nov 20 22:17:37 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EECE21F8AEA for ; Sun, 20 Nov 2011 22:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.394 X-Spam-Level: X-Spam-Status: No, score=-6.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BE-U0IOyQdTS for ; Sun, 20 Nov 2011 22:17:36 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB8921F8ADC for ; Sun, 20 Nov 2011 22:17:36 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAL6HWso015740; Mon, 21 Nov 2011 00:17:34 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 21 Nov 2011 01:17:33 -0500 From: Jakob Heitz To: Christopher Morrow Date: Mon, 21 Nov 2011 01:17:32 -0500 Thread-Topic: [sidr] Route Leaks and BGP Security Thread-Index: AcyoE6xd15/hZYmjR2ysn94zGp8PdwAADQ0w Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A47045264@EUSAACMS0701.eamcs.ericsson.se> References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> <7309FCBCAE981B43ABBE69B31C8D21391A4704525E@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] Route Leaks and BGP Security X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 06:17:37 -0000 > -----Original Message----- > From: christopher.morrow@gmail.com > [mailto:christopher.morrow@gmail.com] On Behalf Of Christopher > Morrow > Sent: Sunday, November 20, 2011 10:06 PM > To: Jakob Heitz > Cc: Danny McPherson; sidr wg list > Subject: Re: [sidr] Route Leaks and BGP Security >=20 > On Mon, Nov 21, 2011 at 12:40 AM, Jakob Heitz > wrote: > > To make the route leak problem tractable, we need a definition. > > Here is my attempt: > > >=20 > danny's draft actually does a decent job of saying what a leak is > (one instance of a leak at least, which is fine), it just doesn't > say how you'd know that from 2 as-hops away... (today, with out bgp > changes and/or external knowledge about the ASes in the AS-Path) >=20 > >=20 > > When S sends a packet to D, that packet should traverse only ASs > that > > S trusts OR that D trusts. If the packet traverses an AS that > NEITHER > > S NOR D trusts, then a route leak has occurred. >=20 > how is this 'trust' known? how does it translate down the chain? I > don't trust AS9001 anymore than 4134 than 4366 than 3 ... I do > happen to fling packets through them though :( You contracted it to provide you connectivity. If it doesn't, it breaks the contract. >=20 > > When a route announcement leaves the set of ASs trusted by its > > originator, Brian's "transit" bit turns off. >=20 > I doubt the originator trusts anyone except itself... and MAYBE it's > transits. >=20 > why mix two topics? :( (also, how does the route know it crossed > this boundary and a bit needs flipping?) When the provider sends it to another customer or another AS that is not contracted to provide connectivity for that route. >=20 > -chris The trust I'm talking about is the trust to provide connectivity, not the trust not to snoop your packets or anything else. From russw@riw.us Mon Nov 21 04:32:44 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE8021F8C0F for ; Mon, 21 Nov 2011 04:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVwKxQCjBcpH for ; Mon, 21 Nov 2011 04:32:44 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1D221F8C0E for ; Mon, 21 Nov 2011 04:32:44 -0800 (PST) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:54639 helo=[192.168.100.52]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RST3D-0002ej-5S for sidr@ietf.org; Mon, 21 Nov 2011 07:32:43 -0500 Message-ID: <4ECA44E2.1050402@riw.us> Date: Mon, 21 Nov 2011 07:32:34 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> <7309FCBCAE981B43ABBE69B31C8D21391A4704525E@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [sidr] Route Leaks and BGP Security X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 12:32:44 -0000 > danny's draft actually does a decent job of saying what a leak is (one > instance of a leak at least, which is fine), it just doesn't say how > you'd know that from 2 as-hops away... (today, with out bgp changes > and/or external knowledge about the ASes in the AS-Path) I came to the conclusion long ago that BGP doesn't carry the information needed to "secure" the AS Path... Maybe this is why BGPsec can't provide the information needed to make intelligent decisions in so many places --because BGP itself doesn't provide that information, and BGPsec only attempts to "secure the semantics of BGP" (and that only in a rather incomplete way). The solution isn't to rule out such problems because they're "unsolvable." There are, in fact, at least two systems that can solve this problem. >> When S sends a packet to D, that packet should traverse >> only ASs that S trusts OR that D trusts. If the packet >> traverses an AS that NEITHER S NOR D trusts, then a route >> leak has occurred. I would generally avoid using packet flow models as a way to describe BGP security issues... BGP, like all routing protocols, is a distributed real time database combined with a set of rules about using the data within the database. By signing the updates, you're attempting to show that the each node participating in the database has followed the rules correctly. The problem is that many of the rules are implicit, rather than explicit, and implicit rules don't lend themselves to being signed. Danny's route leak problem, or needing "beacons," to take routes out of the system, etc., are instances of implicit rules. You have to start with a good model and good requirements, and then work from there. The model the WG has chosen --"we're going to secure BGP semantics," doesn't lead to a good result, simply because not all the semantics are on the table to be secured. :-) Russ From michael.meulle@orange.com Mon Nov 21 07:01:40 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE63A21F8B1A for ; Mon, 21 Nov 2011 07:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZ3UqbEn45lk for ; Mon, 21 Nov 2011 07:01:36 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 11CB721F8B16 for ; Mon, 21 Nov 2011 07:01:36 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 03AA78B8002; Mon, 21 Nov 2011 16:02:39 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 75C218B8004; Mon, 21 Nov 2011 16:02:38 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Nov 2011 16:01:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Nov 2011 16:01:32 +0100 Message-ID: In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391A447FBB8F@EUSAACMS0701.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sidr] Route Leak fix: V free routing Thread-Index: AcyY6i6XGiiG7294R6+FEKAHa5c26ABrfPzgA3F02sA= References: <7309FCBCAE981B43ABBE69B31C8D21391A447FBB8F@EUSAACMS0701.eamcs.ericsson.se> From: To: , , X-OriginalArrivalTime: 21 Nov 2011 15:01:33.0653 (UTC) FILETIME=[75602850:01CCA85E] Cc: sidr@ietf.org Subject: Re: [sidr] Route Leak fix: V free routing X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 15:01:40 -0000 What about using a "BGP community" to set your bit "1/0" and propose = mechanisms to sign the communities tagged by an AS? Mickael -----Message d'origine----- De=A0: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] De la part = de Jakob Heitz Envoy=E9=A0: vendredi 4 novembre 2011 06:18 =C0=A0: Brian Dickson; Stephen Kent Cc=A0: sidr wg list Objet=A0: [sidr] Route Leak fix: V free routing I had a different idea. Model the internet as providers, customers and peers. A provider is above you, a customer is below you and a peer is level to you. Add a "down" bit to the BGPSEC signature block. If an AS sends an update to a customer, it sets the "down" bit. The rule is "V" free routing. Once an update goes "down", it can not come back "up". Sending to peers is always ok. If an AS receives from a customer an update that has a "down" bit in the BGPSEC attribute, it will detect the update as a route leak. Policy will dictate how to deal with it. An AS sets the "down" bit to indicate its wish that the announced prefix stay within the customer's bounds. As it is signed, it can not be changed further down the path. --=20 Jakob Heitz. On Tuesday, November 01, 2011 4:01 PM, Brian Dickson <> wrote: > Upon further consideration, in the interest of not revealing > information that is currently not revealed in BGP, I'll suggest > modifying my earlier proposal as follows: > - the proposed flag needs to exist and be signed by the sender, but > only the last instance of the flag is carried with the route. > - the enforcement of not-promote still needs to be done by the > protocol=20 > - the route will only have the "transit" bit on a per-route basis, of > the last AS (regardless of where demotion occurred, if at all) > - the receiver of a route with the "transit" bit set will generally > already be aware that the receiver is providing transit service, if > legitimately set >=20 > Otherwise, everything else still stands to reason... >=20 > Brian >=20 > On Tue, Nov 1, 2011 at 6:45 PM, Brian Dickson > wrote: >> I have a proposal, to address the route-leak issue. It necessarily >> requires changes to all of the following documents, if it is adopted: >> - threat model >> - protocol >> - requirements >> - NB: this proposed element does not have a corresponding value in >> vanilla BGP.=20 >> - (If BGP had this already, there would not be any route leaks.) >>=20 >> Here is what I propose: >> Add an announced Path Attribute, "Transit", to every BGPSEC signature >> block on an announced prefix. >> "Transit" is a flag bit, and applies to the _announcement_ between >> ASNs in the path. >> Include this Transit flag in the set of things that are signed. >> Make this attribute mandatory to BGPSEC, applied to every signature >> block on a route. >>=20 >> Every BGPSEC peering session is either Transit, or Not-Transit, from >> the perspective of the local AS. >>=20 >> For BGPSEC speakers A and B, all four combinations are legitimate >> scenarios:=20 >> A and B are "strictly speaking, peers" - e.g. 'tier-1' networks A >> and B:=20 >> - A->B is "not-transit" >> - B->A is "not-transit" >> A provides transit to B (or vice versa; exchange labels A and B): >> - A->B is "not-transit" >> - B->A is "transit" >> A and B provide "mutual backup transit": >> - A->B is "transit" >> - B->A is "transit" >>=20 >> The last scenario *should* be extremely rare. The last scenario >> happens to also be the default behavior >> for BGP when unconstrained routing announcements exist, i.e. >> inexperienced network engineers are >> given "enable" and asked to "do BGP". >>=20 >> Here are the specific details and semantics, that in general make >> "the=20 >> right thing" happen, and stop >> route leaks from happening, whether by accident or design. >>=20 >> 1) The "transit" bit can be demoted to "not-transit" (on received, >> signed BGPSEC routes). >> 2) The "transit" bit cannot be promoted from "not-transit" to >> "transit" (on received, signed BGPSEC routes). >> 3) Routes can be originated as "transit" or "not-transit". The >> sensible default behavior is "transit". >> 4) Routes that are received, under a default configuration, SHOULD be >> demoted to "non-transit". >> 4a) Transit ISPs MUST change the (default) configuration on their >> customers' BGP sessions to not-demote their customers' routes. >> 4b) Mutual-Transit arrangements MUST change the (default) >> configuration to not-demote their respective routes. >> 5a) A route with the "transit" bit MAY be sent over any BGPSEC >> peering session. 5b) A route received with the "transit" bit set MAY >> be accepted by the receiver. 6a) A route with the "transit" bit not >> set (i.e. a not-transit route)=20 >> MAY NOT be sent over a peering session that does not permit "transit" >> routes in unmodified (i.e. a peering session that demotes to >> not-transit). >> 6b) A route with the "transit" bit not set (i.e. a non-transit route) >> MAY ONLY be accepted over a peering session configured to send >> "transit" routes (i.e. an "upstream" peer). >>=20 >> If this logic is implemented in the PROTOCOL, and outside of user >> configuration control >> (i.e. limiting user control to "not-demote" and "send-transit"), >> route leaks cannot happen, or at worst have a scope >> of the next local AS if the _receiver_ makes a configuration error. >>=20 >> That is to say, route leaks become, at worst, non-transitive. >>=20 >> Here's a summary of how and why: >> Not-transit (peer) routes can only be sent "downstream", >> where "downstream" can include mutual-transit links. >> Transit routes can be sent everywhere, but only retain >> their "transit" bits when _both_ the sender _and_ receiver agree >> that the link is a transit link. >>=20 >> As soon as a route loses its "transit" bit, it can never regain it, >> whether by accident or design. >>=20 >> Note the following: >> - "Transit" or "not-Transit" is applied on the sender side of >> peering.=20 >> Default is "Transit". >> - "Demote" or "not-Demote" is applied on the receiver side of >> peering.=20 >> Default is "Demote". >> - The originator of a route sets "Transit". >> - "Transit" on a sender-side really means "Do not demote this on >> send".=20 >> - Thus, a sender with "Transit" configured, will never _promote_ a >> non-transit route to transit. >> - And thus, a receiver will automatically filter out >> "non-transit"-marked routes from a combined >> =A0set of routes that includes "transit" and "not-transit", if only >> "transit" are allowed (e.g. an upstream ASN) >>=20 >> [The original motivating discussion follows...] >>=20 >> On Tue, Nov 1, 2011 at 9:57 AM, Stephen Kent wrote: >>> At 4:20 PM -0400 10/29/11, Danny McPherson wrote: >>>=20 >>> Some comments on sidr-bgpsec-threats-00 below.. >>>=20 >>> Most substantial of my concerns is Section 5's "Residual >>> Vulnerabilities", specifically: >>>=20 >>> =A0"BGPSEC has a separate set of residual vulnerabilities: >>>=20 >>> =A0 - BGPSEC is not able to prevent what is usually referred to as >>> =A0=A0=A0 route leaks, because BGP itself does not distinguish = between >>> =A0=A0=A0 transit and non-transit ASes- >>=20 >> This is a chicken-and-egg issue. Since there are several documents >> before=20 >> the WG, some of which have not yet even been accepted by the WG, it >> is premature to say what BGPSEC does and does not do. >>=20 >> We are (in this WG) collectively defining what BGPSEC does and does >> not do.=20 >> The real question is, fundamentally, are there unavoidable >> limitations that make it impossible for BGPSEC to do particular >> things?=20 >>=20 >>> Do we really consider it acceptable that the solution and machinery >>> we're recommending will NOT prevent "route leaks", >>=20 >> IMHO, "No". Frankly, I consider fixing the route leak problem >> non-negotiable. We can and must fix it. It hasn't been fixed in BGP, >> because there has=20 >> always been the >> ability to mess with transitive attributes. Without enforcement, it >> can't truly be fixed. >>=20 >> Since BGPSEC is solving the attribute-tampering problem, the >> practical realities that enabled route leaks, no longer strictly >> exist (within a BGPSEC realm). Which means, we can stop route leaks. >>=20 >> I argue that, because we can, now, we MUST. >>=20 >>> Route leaks represent a violation of an ISPs local policy, i.e., >>> the ISP is propagating routes that it, locally, did not intend to >>> propagate. There is no semantic in BGP that captures this aspect of >>> local policy.=20 >>=20 >> Actually, no. Route leaks represent both a violation of a BGP >> speaker's intended local policy, *and* a violation of other BGP >> speakers' intended policies.=20 >>=20 >> There is nothing that prevents the addition of this new semantic >> (single bit) alongside signatures, >> and in particular within the signed data, which unequivocably >> establishes this intent. >>=20 >> By signing the intent, it becomes globally known as well as locally >> significant. And by being signed, it is tamper-evident. Rejecting >> tampered paths,=20 >> or de-prefering >> tampered paths, eliminates route leaks. >>=20 >> Problem solved (IMNSHO). >>=20 >> Brian >>=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From eosterweil@verisign.com Mon Nov 21 07:13:54 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC5321F8B34 for ; Mon, 21 Nov 2011 07:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0qxicsExCjw for ; Mon, 21 Nov 2011 07:13:54 -0800 (PST) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 6235121F8B2D for ; Mon, 21 Nov 2011 07:13:53 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKTspqqEBnxlK5mzhDNamlKjxH0dtBGDiv@postini.com; Mon, 21 Nov 2011 07:13:53 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id pALFDfRK018004; Mon, 21 Nov 2011 10:13:43 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.132]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Nov 2011 10:13:38 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Mon, 21 Nov 2011 10:13:26 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <7B40776F-D906-46DA-A788-C4E9C0E758A9@verisign.com> <3F1388E3-A694-42C9-AE2F-F12BF15DC86F@verisign.com> <4EC60A7D.3030306@ieca.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 21 Nov 2011 15:13:38.0420 (UTC) FILETIME=[255ED340:01CCA860] Cc: "sidr@ietf.org list" Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 15:13:54 -0000 On Nov 20, 2011, at 1:56 AM, Christopher Morrow wrote: > On Fri, Nov 18, 2011 at 2:34 AM, Sean Turner wrote: >>> that can not do the 'new hotness' (B in your example) you will have to > > do I have to apologize for the MIB refernce? Absolutely not! I was surprised no one gave you props for it! :) Eric From jakob.heitz@ericsson.com Mon Nov 21 07:14:36 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E310B21F8B50 for ; Mon, 21 Nov 2011 07:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.4 X-Spam-Level: X-Spam-Status: No, score=-6.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPSbdlncJnPx for ; Mon, 21 Nov 2011 07:14:36 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3807721F8B49 for ; Mon, 21 Nov 2011 07:14:36 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pALFEWHK015698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Nov 2011 09:14:33 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 21 Nov 2011 10:14:32 -0500 From: Jakob Heitz To: Russ White Date: Mon, 21 Nov 2011 10:15:27 -0500 Thread-Topic: [sidr] Route Leaks and BGP Security Thread-Index: AcyoYEUxfBChAczhQ0+Gwbdj7quabA== Message-ID: References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> <7309FCBCAE981B43ABBE69B31C8D21391A4704525E@EUSAACMS0701.eamcs.ericsson.se> <4ECA44E2.1050402@riw.us> In-Reply-To: <4ECA44E2.1050402@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Route Leaks and BGP Security X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 15:14:37 -0000 V2hlbiBTIHNlbmRzIGEgcGFja2V0IHRvIEQsIHRoYXQgcGFja2V0IHNob3VsZCB0cmF2ZXJzZQ0K b25seSBBU3MgdGhhdCBTIHRydXN0cyBPUiB0aGF0IEQgdHJ1c3RzLiBJZiB0aGUgcGFja2V0DQp0 cmF2ZXJzZXMgYW4gQVMgdGhhdCBORUlUSEVSIFMgTk9SIEQgdHJ1c3RzLCB0aGVuIGEgcm91dGUN CmxlYWsgaGFzIG9jY3VycmVkLg0KDQpJIHdvdWxkIGdlbmVyYWxseSBhdm9pZCB1c2luZyBwYWNr ZXQgZmxvdyBtb2RlbHMgYXMgYSB3YXkgdG8gZGVzY3JpYmUNCkJHUCBzZWN1cml0eSBpc3N1ZXMu Li4NCg0KVGhlIHVsdGltYXRlIGdvYWwgaXMgdG8gcHJvdGVjdCB0aGUgcGFja2V0IGZsb3csIHNv IEkgd2VudCBiYWNrIHRvIHRoYXQgdG8gY29tZSB1cCB3aXRoIGEgZGVmaW5pdGlvbi4gSG93IHRv IHRyYW5zbGF0ZSB0aGF0IGludG8gQkdQIGlzIGp1c3QgdGhlIG5leHQgc3RlcC4NCg0K From randy@psg.com Mon Nov 21 08:09:57 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085A221F8ADC for ; Mon, 21 Nov 2011 08:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYejLQEhHyPq for ; Mon, 21 Nov 2011 08:09:56 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA8821F8B36 for ; Mon, 21 Nov 2011 08:09:55 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RSWRN-00052S-Nr; Mon, 21 Nov 2011 16:09:54 +0000 Date: Mon, 21 Nov 2011 18:09:49 +0200 Message-ID: From: Randy Bush To: Russ White In-Reply-To: <4ECA44E2.1050402@riw.us> References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> <7309FCBCAE981B43ABBE69B31C8D21391A4704525E@EUSAACMS0701.eamcs.ericsson.se> <4ECA44E2.1050402@riw.us> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Route Leaks and BGP Security X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 16:09:57 -0000 > The solution isn't to rule out such problems because they're > "unsolvable." There are, in fact, at least two systems that can solve > this problem. in the harsh realities such as o a significant portion of the internet's isps will not publish peering and customer business relationships, o ASs are not homogenous, A gives B local peering and international transit in frankfurt, but B may have no relationship with A in new york, or B may be A's customer in new york, and you will never know (and you do not want to see how this is done if you are anywhere near a meal) o etc. could you point to where two such systems are documented? otherwise, i have to conclude that o this is just a repeat of the non-sense which wasted years of time of the last ietf attempt in this area, o and we should do what we know how to do, which, though not a total panacea, will be a non-trivial improvement on the current situation, and o and we should leave the research to an irtf wg. randy From dougm@nist.gov Mon Nov 21 08:37:15 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979F511E80C0 for ; Mon, 21 Nov 2011 08:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvA5o2ueZL9a for ; Mon, 21 Nov 2011 08:37:11 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 43AE811E80C9 for ; Mon, 21 Nov 2011 08:37:10 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 21 Nov 2011 11:37:08 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 21 Nov 2011 11:37:08 -0500 From: "Montgomery, Douglas" To: "michael.meulle@orange.com" , "jakob.heitz@ericsson.com" , "brian.peter.dickson@gmail.com" , Stephen Kent Date: Mon, 21 Nov 2011 11:37:06 -0500 Thread-Topic: [sidr] Route Leak fix: V free routing Thread-Index: Acyoa7v2Ab7mGKLzRaWfJukAxZBETw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Route Leak fix: V free routing X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 16:37:15 -0000 These ideas have floated around for 20+ years. They have even appeared in early BGP specs ... See "LINK TYPE" in http://www.ietf.org/rfc/rfc1105.txt. I actually think this is a useful idea, but the discussion always rat holes in the supposition of absolute filtering rules and proof by counter examples. I think it would be simple for transmitters to indicate and sign their view of the peering relationship they are sending an update over. Customer, provider, peer, or unspecified. (where/how you encode this is a detail, I would suggest in the PATH SIG unless we decide to take on the more general approach below). What receivers do with that information ... Just like validation state, would be a matter of local policy. Worse case is everyone chooses unspecified and we waste two bits under the signature. Best case for those who don't care about declaring who their customers/providers are to their customers/providers .... Then receivers can choose to filter "V" routes if they wish. dougm --=20 Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / NIST On 11/21/11 10:01 AM, "michael.meulle@orange.com" wrote: >What about using a "BGP community" to set your bit "1/0" and propose >mechanisms to sign the communities tagged by an AS? > >Mickael > >-----Message d'origine----- >De : sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] De la part de >Jakob Heitz >Envoy=E9 : vendredi 4 novembre 2011 06:18 >=C0 : Brian Dickson; Stephen Kent >Cc : sidr wg list >Objet : [sidr] Route Leak fix: V free routing > >I had a different idea. > >Model the internet as providers, customers and peers. >A provider is above you, a customer is below you and >a peer is level to you. > >Add a "down" bit to the BGPSEC signature block. >If an AS sends an update to a customer, it sets the >"down" bit. > >The rule is "V" free routing. >Once an update goes "down", it can not come back "up". >Sending to peers is always ok. >If an AS receives from a customer an update >that has a "down" bit in the BGPSEC attribute, >it will detect the update as a route leak. >Policy will dictate how to deal with it. > >An AS sets the "down" bit to indicate its wish that >the announced prefix stay within the customer's bounds. >As it is signed, it can not be changed further down >the path. > >-- >Jakob Heitz. > >On Tuesday, November 01, 2011 4:01 PM, Brian Dickson <> wrote: > >> Upon further consideration, in the interest of not revealing >> information that is currently not revealed in BGP, I'll suggest >> modifying my earlier proposal as follows: >> - the proposed flag needs to exist and be signed by the sender, but >> only the last instance of the flag is carried with the route. >> - the enforcement of not-promote still needs to be done by the >> protocol >> - the route will only have the "transit" bit on a per-route basis, of >> the last AS (regardless of where demotion occurred, if at all) >> - the receiver of a route with the "transit" bit set will generally >> already be aware that the receiver is providing transit service, if >> legitimately set >> >> Otherwise, everything else still stands to reason... >> >> Brian >> >> On Tue, Nov 1, 2011 at 6:45 PM, Brian Dickson >> wrote: >>> I have a proposal, to address the route-leak issue. It necessarily >>> requires changes to all of the following documents, if it is adopted: >>> - threat model >>> - protocol >>> - requirements >>> - NB: this proposed element does not have a corresponding value in >>> vanilla BGP. >>> - (If BGP had this already, there would not be any route leaks.) >>> >>> Here is what I propose: >>> Add an announced Path Attribute, "Transit", to every BGPSEC signature >>> block on an announced prefix. >>> "Transit" is a flag bit, and applies to the _announcement_ between >>> ASNs in the path. >>> Include this Transit flag in the set of things that are signed. >>> Make this attribute mandatory to BGPSEC, applied to every signature >>> block on a route. >>> >>> Every BGPSEC peering session is either Transit, or Not-Transit, from >>> the perspective of the local AS. >>> >>> For BGPSEC speakers A and B, all four combinations are legitimate >>> scenarios: >>> A and B are "strictly speaking, peers" - e.g. 'tier-1' networks A >>> and B: >>> - A->B is "not-transit" >>> - B->A is "not-transit" >>> A provides transit to B (or vice versa; exchange labels A and B): >>> - A->B is "not-transit" >>> - B->A is "transit" >>> A and B provide "mutual backup transit": >>> - A->B is "transit" >>> - B->A is "transit" >>> >>> The last scenario *should* be extremely rare. The last scenario >>> happens to also be the default behavior >>> for BGP when unconstrained routing announcements exist, i.e. >>> inexperienced network engineers are >>> given "enable" and asked to "do BGP". >>> >>> Here are the specific details and semantics, that in general make >>> "the >>> right thing" happen, and stop >>> route leaks from happening, whether by accident or design. >>> >>> 1) The "transit" bit can be demoted to "not-transit" (on received, >>> signed BGPSEC routes). >>> 2) The "transit" bit cannot be promoted from "not-transit" to >>> "transit" (on received, signed BGPSEC routes). >>> 3) Routes can be originated as "transit" or "not-transit". The >>> sensible default behavior is "transit". >>> 4) Routes that are received, under a default configuration, SHOULD be >>> demoted to "non-transit". >>> 4a) Transit ISPs MUST change the (default) configuration on their >>> customers' BGP sessions to not-demote their customers' routes. >>> 4b) Mutual-Transit arrangements MUST change the (default) >>> configuration to not-demote their respective routes. >>> 5a) A route with the "transit" bit MAY be sent over any BGPSEC >>> peering session. 5b) A route received with the "transit" bit set MAY >>> be accepted by the receiver. 6a) A route with the "transit" bit not >>> set (i.e. a not-transit route) >>> MAY NOT be sent over a peering session that does not permit "transit" >>> routes in unmodified (i.e. a peering session that demotes to >>> not-transit). >>> 6b) A route with the "transit" bit not set (i.e. a non-transit route) >>> MAY ONLY be accepted over a peering session configured to send >>> "transit" routes (i.e. an "upstream" peer). >>> >>> If this logic is implemented in the PROTOCOL, and outside of user >>> configuration control >>> (i.e. limiting user control to "not-demote" and "send-transit"), >>> route leaks cannot happen, or at worst have a scope >>> of the next local AS if the _receiver_ makes a configuration error. >>> >>> That is to say, route leaks become, at worst, non-transitive. >>> >>> Here's a summary of how and why: >>> Not-transit (peer) routes can only be sent "downstream", >>> where "downstream" can include mutual-transit links. >>> Transit routes can be sent everywhere, but only retain >>> their "transit" bits when _both_ the sender _and_ receiver agree >>> that the link is a transit link. >>> >>> As soon as a route loses its "transit" bit, it can never regain it, >>> whether by accident or design. >>> >>> Note the following: >>> - "Transit" or "not-Transit" is applied on the sender side of >>> peering. >>> Default is "Transit". >>> - "Demote" or "not-Demote" is applied on the receiver side of >>> peering. >>> Default is "Demote". >>> - The originator of a route sets "Transit". >>> - "Transit" on a sender-side really means "Do not demote this on >>> send". >>> - Thus, a sender with "Transit" configured, will never _promote_ a >>> non-transit route to transit. >>> - And thus, a receiver will automatically filter out >>> "non-transit"-marked routes from a combined >>> set of routes that includes "transit" and "not-transit", if only >>> "transit" are allowed (e.g. an upstream ASN) >>> >>> [The original motivating discussion follows...] >>> >>> On Tue, Nov 1, 2011 at 9:57 AM, Stephen Kent wrote: >>>> At 4:20 PM -0400 10/29/11, Danny McPherson wrote: >>>> >>>> Some comments on sidr-bgpsec-threats-00 below.. >>>> >>>> Most substantial of my concerns is Section 5's "Residual >>>> Vulnerabilities", specifically: >>>> >>>> "BGPSEC has a separate set of residual vulnerabilities: >>>> >>>> - BGPSEC is not able to prevent what is usually referred to as >>>> route leaks, because BGP itself does not distinguish between >>>> transit and non-transit ASes- >>> >>> This is a chicken-and-egg issue. Since there are several documents >>> before >>> the WG, some of which have not yet even been accepted by the WG, it >>> is premature to say what BGPSEC does and does not do. >>> >>> We are (in this WG) collectively defining what BGPSEC does and does >>> not do. >>> The real question is, fundamentally, are there unavoidable >>> limitations that make it impossible for BGPSEC to do particular >>> things? >>> >>>> Do we really consider it acceptable that the solution and machinery >>>> we're recommending will NOT prevent "route leaks", >>> >>> IMHO, "No". Frankly, I consider fixing the route leak problem >>> non-negotiable. We can and must fix it. It hasn't been fixed in BGP, >>> because there has >>> always been the >>> ability to mess with transitive attributes. Without enforcement, it >>> can't truly be fixed. >>> >>> Since BGPSEC is solving the attribute-tampering problem, the >>> practical realities that enabled route leaks, no longer strictly >>> exist (within a BGPSEC realm). Which means, we can stop route leaks. >>> >>> I argue that, because we can, now, we MUST. >>> >>>> Route leaks represent a violation of an ISPs local policy, i.e., >>>> the ISP is propagating routes that it, locally, did not intend to >>>> propagate. There is no semantic in BGP that captures this aspect of >>>> local policy. >>> >>> Actually, no. Route leaks represent both a violation of a BGP >>> speaker's intended local policy, *and* a violation of other BGP >>> speakers' intended policies. >>> >>> There is nothing that prevents the addition of this new semantic >>> (single bit) alongside signatures, >>> and in particular within the signed data, which unequivocably >>> establishes this intent. >>> >>> By signing the intent, it becomes globally known as well as locally >>> significant. And by being signed, it is tamper-evident. Rejecting >>> tampered paths, >>> or de-prefering >>> tampered paths, eliminates route leaks. >>> >>> Problem solved (IMNSHO). >>> >>> Brian >>> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From russw@riw.us Mon Nov 21 08:57:51 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180811F0C58 for ; Mon, 21 Nov 2011 08:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohg8ILZgBEtR for ; Mon, 21 Nov 2011 08:57:50 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 920FA21F8888 for ; Mon, 21 Nov 2011 08:57:50 -0800 (PST) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:64717 helo=[192.168.100.52]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RSXBl-0005lt-Bw; Mon, 21 Nov 2011 11:57:49 -0500 Message-ID: <4ECA8306.9070009@riw.us> Date: Mon, 21 Nov 2011 11:57:42 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Randy Bush References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> <7309FCBCAE981B43ABBE69B31C8D21391A4704525E@EUSAACMS0701.eamcs.ericsson.se> <4ECA44E2.1050402@riw.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Cc: sidr@ietf.org Subject: Re: [sidr] Route Leaks and BGP Security X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 16:57:51 -0000 > o a significant portion of the internet's isps will not publish > peering and customer business relationships, You can't secure what you don't tell anyone about. Security is about allowing others to compare the current state against what the state should be. What you're asking for is to ask someone else to take some specific action for you without telling them what that action should be. An impossibility. > o ASs are not homogenous, A gives B local peering and international > transit in frankfurt, but B may have no relationship with A in > new york, or B may be A's customer in new york, and you will never > know (and you do not want to see how this is done if you are > anywhere near a meal) These can be accounted for in some of the systems that have been proposed in the past, or are now available. > o this is just a repeat of the non-sense which wasted years of time > of the last ietf attempt in this area, Which is a worse waste of time --designing a solution first, then fitting the requirements around it, or figuring out what the problem is, then thinking through possible solutions? :-) Russ From robert@raszuk.net Mon Nov 21 11:53:29 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D904F11E80C0 for ; Mon, 21 Nov 2011 11:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEfvWgC9ZIpa for ; Mon, 21 Nov 2011 11:53:25 -0800 (PST) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id A279611E8096 for ; Mon, 21 Nov 2011 11:53:25 -0800 (PST) Received: (qmail 22463 invoked by uid 399); 21 Nov 2011 19:53:24 -0000 Received: from unknown (HELO ?192.168.1.57?) (83.24.180.210) by mail1310.opentransfer.com with ESMTP; 21 Nov 2011 19:53:24 -0000 X-Originating-IP: 83.24.180.210 Message-ID: <4ECAAC34.8080204@raszuk.net> Date: Mon, 21 Nov 2011 20:53:24 +0100 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Russ White , Randy Bush References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> <7309FCBCAE981B43ABBE69B31C8D21391A4704525E@EUSAACMS0701.eamcs.ericsson.se> <4ECA44E2.1050402@riw.us> <4ECA8306.9070009@riw.us> In-Reply-To: <4ECA8306.9070009@riw.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] Route Leaks and BGP Security X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 19:53:30 -0000 >> o a significant portion of the internet's isps will not publish >> peering and customer business relationships, Randy, This is very true statement how every last week we have had a number of conversations where the same significant portions of ISPs expressed very great interest in increase their revenues in the context of CDNs. So to get some money from the large content providers like Akamai or Google they are willing to expose their peering relations just to let those big guys may an intelligent content query redirection. I do know this is a bit outside of the scope of this WG, but the requirement is common and with addressing one we could perhaps address the other one in one shot. So if we would propose a solution which only asks to advertise given AS's neighboring ASes by peering to them of course without disclosing any policy one may have .. do you think this would not be a doable proposal ? Regards, R. > On 2011-11-21 17:57, Russ White wrote: > >> o a significant portion of the internet's isps will not publish >> peering and customer business relationships, > > You can't secure what you don't tell anyone about. Security is about > allowing others to compare the current state against what the state > should be. What you're asking for is to ask someone else to take some > specific action for you without telling them what that action should be. > An impossibility. > >> o ASs are not homogenous, A gives B local peering and international >> transit in frankfurt, but B may have no relationship with A in >> new york, or B may be A's customer in new york, and you will never >> know (and you do not want to see how this is done if you are >> anywhere near a meal) > > These can be accounted for in some of the systems that have been > proposed in the past, or are now available. > >> o this is just a repeat of the non-sense which wasted years of time >> of the last ietf attempt in this area, > > Which is a worse waste of time --designing a solution first, then > fitting the requirements around it, or figuring out what the problem is, > then thinking through possible solutions? > > :-) > > Russ > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > From shane@castlepoint.net Mon Nov 21 15:08:56 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B29F11E8128 for ; Mon, 21 Nov 2011 15:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ML4evbB51USX for ; Mon, 21 Nov 2011 15:08:55 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 6561111E80D5 for ; Mon, 21 Nov 2011 15:08:55 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id D446F268063; Mon, 21 Nov 2011 16:08:54 -0700 (MST) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 21 Nov 2011 16:08:54 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=63039; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Shane Amante In-Reply-To: Date: Mon, 21 Nov 2011 16:08:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7D344AD5-B101-4BC1-8522-2259DB9853E4@castlepoint.net> References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1251.1) Cc: sidr wg list Subject: Re: [sidr] Route Leaks and BGP Security X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 23:08:56 -0000 Hi Chris, On Nov 20, 2011, at 10:35 PM, Christopher Morrow wrote: > On Wed, Nov 16, 2011 at 11:23 PM, Danny McPherson = wrote: >>=20 >> Team, >> I've updated this draft based on some feedback received already. = Given >> the discussion at the WG session, and the list discussion as of late, = I'd like >> to ask that it become a WG item and used to inform the BGP Threat = Model >> document -- particularly with regards to what's an acceptable = residual risk and >> what is not. Once that's comprehensive it can be used to inform = secure routing >> requirements documents in the working group, and then we can begin = assessing >> the feasibility of reducing various risks. >=20 > "The authors believe the capability to prevent leaks should be a=09 > first-order engineering objective in any secure routing architecture." >=20 > So, in the simple scenario laid out, the customer is filtered by the > isp's, no? and the filter data is built with something like: take irr > data, meld with rpki data, create filter-lists. >=20 > The rpki data gives the isps an ability to filter the customer > announcements, which would stop the leaks. Is the thing you really > want to outline in a draft the process to link the > resource-certification data with the existing IRR data and create > better prefix/as-path filters? As the -01 draft states: ---snip--- Discussion of out of band methods to mitigate this attack are beyond the scope of this document, as it's objective is to inform routing protocol design choices currently being considered within the IETF's SIDR Working Group. ---snip--- > I think one item that was asked for on the list (or perhaps in the > meeting) was: How can you know a route you see is a leak? >=20 > Taken another way, in the case of your example: >=20 > victim - isp2 - attacker - isp1 >=20 > how is the victim to know that this path isn't proper? > what in the update says that? That's the point. :-) At present, nothing being "secured" in the = UPDATE, (specifically AS_PATH wrt BGPSec), will tell you that the UPDATE = was sent through a legitimate control-plane path vs. an illegitimate = control-plane path. In today's networks, the means to control the propagation of a = particular BGP route are through configuration of 'policy' locally on = routers, (ASBR's/PE's), that look for a combination of /one or more/ = _BGP_attributes_ in the BGP route itself to limit its propagation. As = one specific example, an operator of an AS typically configures their = ingress ASBR's to assign a specific standard BGP community that says = something like: - this is a customer route; - this is a peer route (I would note that these BGP standard communities are 'local' to and = only have meaning within the operator of their particular AS. An = operator should NOT or would NOT "trust" third-parties, e.g.: their = customers or peers, to set and send these communities to them for lots = of obvious reasons). When a BGP route travels to that operator's egress ASBR's, the egress = ASBR then has a locally configured policy that looks for the locally = significant BGP community string that says: "this is a customer route", = in which case the route is sent out of both peer & customer eBGP = sessions. OTOH, if the eBGP policy at the egress ASBR determines, based = on the locally significant BGP community string assigned to a BGP route, = "this is a peer route", the action in that locally configured policy at = peer eBGP sessions is to drop (not announce outbound) that particular = UPDATE; whereas, the action at customer eBGP sessions is to announce = that UPDATE outbound. Locally significant BGP communities + locally configured policy are just = one method that could be used, but likely the most widely used. = Depending on the size of one's network other BGP Attributes + locally = configured policy may be used. > is there other data that could be used (outside of bgp) to tell the > victim that the path is improper? IMHO, and as I think Russ has pointed out, BGP was only (?) designed to = express reachability, not to carry or forward _policy_. At present, = nothing in the BGP protocol disseminates _policy_[1]. Instead, policy = to control propagation of BGP routing information is only known to = routers via out-of-band configuration (through CLI or NETCONF), either = manually or through automated methods. -shane [1] The only minor exception I can think of to this is the well-known = NO_EXPORT or NO_ADVERTISE BGP communities. However, those have an = extremely limited scope -- specifically, both communities are only = exchanged between _directly_ connected adjacent ASN's. I would add that = since BGPSec does not make any attempt to sign the BGP community = Attribute, it follows that even in this most limited case BGPSec is not = able to certify (authenticate?) that a given BGP route *should* or = *should not* be propagated to AS'es 2+ hops away. What if one stripped = the NO_EXPORT or NO_ADVERTISE community off and re-announced that BGP = route -- is that not considered a MiTM attack, just as bad (or, worse?) = as fraudulently inserting one's self into the AS_PATH?= From christopher.morrow@gmail.com Mon Nov 21 18:47:30 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3538121F8AC3 for ; Mon, 21 Nov 2011 18:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.258 X-Spam-Level: X-Spam-Status: No, score=-103.258 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xk5yTTH2v0xL for ; Mon, 21 Nov 2011 18:47:29 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3298321F8ABD for ; Mon, 21 Nov 2011 18:47:29 -0800 (PST) Received: by ggnp4 with SMTP id p4so775379ggn.31 for ; Mon, 21 Nov 2011 18:47:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PSQpT879iJ5YK+WfBNLfHE+7pC8lkz8wpO81zhSjGHA=; b=OjkH6BxwpPctCInTMXGRgLm9l/SZf/hWea4CpBsr70xx/vYYDqDy7d+AfwaTf6F8lM vKLx5h9yorvPo1EGWA+7lCjd9ySVDIaWKUdU57VyfCxf6agbGhy+OgQx1gOP0EN6rJcY fsY9k0ZvLQLe2dgbYmCswYK6AcFHVJ2Xck+8E= MIME-Version: 1.0 Received: by 10.68.54.106 with SMTP id i10mr34022575pbp.60.1321930048344; Mon, 21 Nov 2011 18:47:28 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.68.43.201 with HTTP; Mon, 21 Nov 2011 18:47:28 -0800 (PST) In-Reply-To: <7D344AD5-B101-4BC1-8522-2259DB9853E4@castlepoint.net> References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> <7D344AD5-B101-4BC1-8522-2259DB9853E4@castlepoint.net> Date: Mon, 21 Nov 2011 21:47:28 -0500 X-Google-Sender-Auth: Xjein1lHREYU6k3a4nJaMUWdAVc Message-ID: From: Christopher Morrow To: Shane Amante Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] Route Leaks and BGP Security X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 02:47:30 -0000 On Mon, Nov 21, 2011 at 6:08 PM, Shane Amante wrote= : > Hi Chris, howdy! > On Nov 20, 2011, at 10:35 PM, Christopher Morrow wrote: >> On Wed, Nov 16, 2011 at 11:23 PM, Danny McPherson wrote: >>> >>> Team, >>> I've updated this draft based on some feedback received already. =A0Giv= en >>> the discussion at the WG session, and the list discussion as of late, I= 'd like >>> to ask that it become a WG item and used to inform the BGP Threat Model >>> document -- particularly with regards to what's an acceptable residual = risk and >>> what is not. =A0Once that's comprehensive it can be used to inform secu= re routing >>> requirements documents in the working group, and then we can begin asse= ssing >>> the feasibility of reducing various risks. >> >> "The authors believe the capability to prevent leaks should be a >> first-order engineering objective in any secure routing architecture." >> >> So, in the simple scenario laid out, the customer is filtered by the >> isp's, no? and the filter data is built with something like: =A0take irr >> data, meld with rpki data, create filter-lists. >> >> The rpki data gives the isps an ability to filter the customer >> announcements, which would stop the leaks. Is the thing you really >> want to outline in a draft the process to link the >> resource-certification data with the existing IRR data and create >> better prefix/as-path filters? > > As the -01 draft states: > ---snip--- > =A0Discussion of out of band methods to mitigate this attack are beyond > =A0the scope of this document, as it's objective is to inform routing > =A0protocol design choices currently being considered within the IETF's > =A0SIDR Working Group. > ---snip--- > yea, that's cheating :) > >> I think one item that was asked for on the list (or perhaps in the >> meeting) was: How can you know a route you see is a leak? >> >> Taken another way, in the case of your example: >> >> victim - isp2 - attacker - isp1 >> >> how is the victim to know that this path isn't proper? >> what in the update says that? > > That's the point. =A0:-) =A0At present, nothing being "secured" in the UP= DATE, (specifically AS_PATH wrt BGPSec), will tell you that the UPDATE was = sent through a legitimate control-plane path vs. an illegitimate control-pl= ane path. > agreed. > In today's networks, the means to control the propagation of a particular= BGP route are through configuration of 'policy' locally on routers, (ASBR'= s/PE's), that look for a combination of /one or more/ _BGP_attributes_ in t= he BGP route itself to limit its propagation. =A0As one specific example, a= n operator of an AS typically configures their ingress ASBR's to assign a s= pecific standard BGP community that says something like: > - this is a customer route; > - this is a peer route > (I would note that these BGP standard communities are 'local' to and only= have meaning within the operator of their particular AS. =A0An operator sh= ould NOT or would NOT "trust" third-parties, e.g.: their customers or peers= , to set and send these communities to them for lots of obvious reasons). > ok, so if we step forward and ask for 'give me an attribute to indicate customer/peer/other', would we then trust that? it'd be (presumably) set per as-hop, is that anymore trustworthy than the communities supposed above? (I'd also ask what the rules are for setting this sort of thing, but I don't think that matters since we can't really trust the value in it) > When a BGP route travels to that operator's egress ASBR's, the egress ASB= R then has a locally configured policy that looks for the locally significa= nt BGP community string that says: "this is a customer route", in which cas= e the route is sent out of both peer & customer eBGP sessions. =A0OTOH, if = the eBGP policy at the egress ASBR determines, based on the locally signifi= cant BGP community string assigned to a BGP route, "this is a peer route", = the action in that locally configured policy at peer eBGP sessions is to dr= op (not announce outbound) that particular UPDATE; whereas, the action at c= ustomer eBGP sessions is to announce that UPDATE outbound. > > Locally significant BGP communities + locally configured policy are just = one method that could be used, but likely the most widely used. =A0Dependin= g on the size of one's network other BGP Attributes + locally configured po= licy may be used. > > >> is there other data that could be used (outside of bgp) to tell the >> victim that the path is improper? > > IMHO, and as I think Russ has pointed out, BGP was only (?) designed to e= xpress reachability, not to carry or forward _policy_. =A0At present, nothi= ng in the BGP protocol disseminates _policy_[1]. =A0Instead, policy to cont= rol propagation of BGP routing information is only known to routers via out= -of-band configuration (through CLI or NETCONF), either manually or through= automated methods. > yup, I don't think we're going to get to the fully publicly exposed policy world though... are we? (we can't, I think, expect everyone to expose that sort of thing, never mind keep it updated) > -shane > > [1] The only minor exception I can think of to this is the well-known NO_= EXPORT or NO_ADVERTISE BGP communities. =A0However, those have an extremely= limited scope -- specifically, both communities are only exchanged between= _directly_ connected adjacent ASN's. =A0I would add that since BGPSec does= not make any attempt to sign the BGP community Attribute, it follows that = even in this most limited case BGPSec is not able to certify During the design team discussions of what parts of bgp to sign, the decision was made not to cover communities and other attributes since.. which community means what? which are important? which aren't? can one AS set 701:666 and send that along to 701? what about 70:112? (as rob austein said: "What are the security semantics of a community?") Also, what about (as danny pointed out a few meetings ago) the networks that strip all communities on ingress so routes with all relevant attributes equal but different community sets don't cause extra headache/etc. > (authenticate?) that a given BGP route *should* or *should not* be propag= ated to AS'es 2+ hops away. =A0What if one stripped the NO_EXPORT or NO_ADV= ERTISE community off and re-announced that BGP route -- is that not conside= red a MiTM attack, just as bad (or, worse?) as fraudulently inserting one's= self into the AS_PATH? yup... no-export/advertise were taken as 'advisory' communities that networks MAY heed, but certainly weren't bound to do so. So, back to the question: "Given BGP as it is today, how do you know if a route is a leak or not?" I suppose documenting: "One leak scenario is " is a fine thing, does it help to actually fix the problem though? I think what I heard in the meeting and on the thread(s) here was: "Sure leaks are important, there's not a way devised so far that distinguishes a 'leak' route from a 'normal' route, more than 1 as-hop from the 'source' of the leak. In the id/draft: isp1 isp2 - me \ / AS1 I can't tell at 'me' that the route I see is a 'leak', just that I see an as-path that is isp1-as1-isp2. -chris From danny@tcb.net Mon Nov 21 19:10:07 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839A621F84B4 for ; Mon, 21 Nov 2011 19:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbfXnprRCwzf for ; Mon, 21 Nov 2011 19:10:05 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 0974F21F84B0 for ; Mon, 21 Nov 2011 19:10:03 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id C3071268063; Mon, 21 Nov 2011 20:10:02 -0700 (MST) Received: from dul1dmcphers-m1.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 21 Nov 2011 20:10:02 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=64554; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Mon, 21 Nov 2011 22:09:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <72E12AD7-CFAF-4FBD-8A98-F93038F7E8FB@tcb.net> References: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> To: Stephen Kent X-Mailer: Apple Mail (2.1084) Cc: sidr@ietf.org Subject: Re: [sidr] Origin Ops, TALs and Local TAs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 03:10:07 -0000 On Nov 16, 2011, at 2:50 AM, Stephen Kent wrote: >=20 >> Here's my primary question. If I wanted to form a 'federation' of = sorts for >> resiliency would I have to use additional TALs in conjunction with my >> LTA and paracertificate hierarchy? If so, can an RP include some = sort of >> filter to constrain what a TA can assert as within their resource = holdings? >=20 > not sure what a federation is, but, yes, an RP can constrain what a TA > is allowed to assert, via a constraints file. Ahh, this makes good sense. >> That is, because for LTA to work every relying party in the = transaction >> path (i.e., source and destination networks, as well as intermediate = RPs) >> would need to override the putative [global] TA RPKI for every other >> operators resources and generate a paracertificate hierarchy therein, >> is that right? >=20 > I don't understand all of the words above. Apologies for the loose terminology here.. Try this.. AS1 --- ISP1 (AS2) --- ISP2 (AS3) --- AS4 In the case of LTA if these four parties wish to transact their = constraints files=20 (or shared "non-putative" RPKI TAs) must be familiar and synchronized = with each other via some out of band mechanism - i.e., they either have to: 1) synchronize LTA contents across the set 2) share a common non-putative TA that magically does this and in doing so, they likely would want to constrain what a TA is = allowed to assert, via a constraints file, as noted above? That is, LTA for the local AS doesn't fix the = multi-AS/multi-administrator/RP=20 issue, and so some synchronization or shared non-putative TA needs to be=20= developed in they desire autonomy outside of the putative set. =20 Is that correct? >> And if that's the case, wouldn't it be simpler for RPs to be able to >> associate resources with each trust anchor rather than trusting them = to >> convey to the RP what resources they are authoritative for? >=20 > LTA management allows this, but it becomes very complex to do well if = there are too many data items to manage. Yeah, that's what I'm mulling... Thanks,=20 -danny= From terry@terrym.net Mon Nov 21 20:15:18 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1C61F0C4C for ; Mon, 21 Nov 2011 20:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQRqNHg5UiOQ for ; Mon, 21 Nov 2011 20:15:17 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 55DB61F0C43 for ; Mon, 21 Nov 2011 20:15:17 -0800 (PST) Received: by ggnp4 with SMTP id p4so844355ggn.31 for ; Mon, 21 Nov 2011 20:15:16 -0800 (PST) Received: by 10.101.115.1 with SMTP id s1mr3639562anm.164.1321935316343; Mon, 21 Nov 2011 20:15:16 -0800 (PST) Received: from [192.168.1.105] (c114-77-161-74.fitzg3.qld.optusnet.com.au. [114.77.161.74]) by mx.google.com with ESMTPS id h28sm35562468ani.17.2011.11.21.20.15.13 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Nov 2011 20:15:15 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Terry Manderson In-Reply-To: Date: Tue, 22 Nov 2011 14:15:09 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> <7D344AD5-B101-4BC1-8522-2259DB9853E4@castlepoint.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] Route Leaks and BGP Security X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 04:15:18 -0000 Speaking for myself on this one. On 22/11/2011, at 12:47 PM, Christopher Morrow wrote: >=20 > ok, so if we step forward and ask for 'give me an attribute to > indicate customer/peer/other', would we then trust that? it'd be > (presumably) set per as-hop, is that anymore trustworthy than the > communities supposed above? >=20 > (I'd also ask what the rules are for setting this sort of thing, but I > don't think that matters since we can't really trust the value in it) >=20 So lets say (hypothetically) we adopt a requirement of this system to = allow a relying party to parse a route and know if it is intended or not = by some construction of verifiable information. I can't, for the life of me, see a transitive attribute _in_ BGP (signed = or otherwise) making a positive step in trying to secure intent of the = local AS as effected by a routing domain 2+ hops away. >>=20 >>=20 >=20 > yup, I don't think we're going to get to the fully publicly exposed > policy world though... are we? (we can't, I think, expect everyone to > expose that sort of thing, never mind keep it updated) History tells us we are (for the most part) inept at doing so, even with = tools available. But what we do know is that when policy is implemented, the results are = transparent and can be seen (ris, routeviews, et al) by anyone who cares to look. >=20 > yup... no-export/advertise were taken as 'advisory' communities that > networks MAY heed, but certainly weren't bound to do so. >=20 > So, back to the question: > "Given BGP as it is today, how do you know if a route is a leak or = not?" >=20 > I suppose documenting: "One leak scenario is " is a fine > thing, does it help to actually fix the problem though? I think what I > heard in the meeting and on the thread(s) here was: "Sure leaks are > important, there's not a way devised so far that distinguishes a > 'leak' route from a 'normal' route, more than 1 as-hop from the > 'source' of the leak. >=20 > In the id/draft: >=20 > isp1 isp2 - me > \ / > AS1 >=20 > I can't tell at 'me' that the route I see is a 'leak', just that I see > an as-path that is isp1-as1-isp2. The bit I think that is missing is some knowledge that isp1 asserts it = has valid routing through isp2, and any other potential 'true' paths. = (noting AS1 is considered the 'Serleena' here) =46rom what I recall draft-huston-sidr-aao-profile takes a step in that = direction. (insert my reluctance about tightly binding routing = operations to allocation practice) in such that it only publicises the = valid paths, through subsequent AAO's by by other ASNs. Thus if an AAO = (in my reading) is created by isp1 with only an adjacency to isp2. It = provides "me" with an ability to say that the received route with AS1 on = path is invalid. The AAO doesn't dive into local policy, and if isp1 has a private = peering with AS3, then it need not put that in an AAO and thus the = business dealings remain private - everything else ends up being seen in = routeviews over time. So this is one way... but not the only way. The killer problem here is that partial deployments will create path = islands, where only a number of the ASN hops have created AAO objects = and thus a path validity exercise will still fall into a potential leak = trap until all ASNs get there. The question then could then be, "is it = o.k. for the answer to route leaks to be near unusable until we have a = significant deployment" Cheers, T. From christopher.morrow@gmail.com Mon Nov 21 21:13:58 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165731F0C57 for ; Mon, 21 Nov 2011 21:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.551 X-Spam-Level: X-Spam-Status: No, score=-103.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+a-mRhe-hpj for ; Mon, 21 Nov 2011 21:13:57 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6DA1F0C43 for ; Mon, 21 Nov 2011 21:13:57 -0800 (PST) Received: by ghrr14 with SMTP id r14so4344436ghr.31 for ; Mon, 21 Nov 2011 21:13:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Wx/LNbA2DFoZQU0NhFmUt6nunA6GZn6LBmAiku/aTcg=; b=ppP6oEBdMUI80NfehLy6deIb7zaHGTi+A6AYDLywXof1j+cjezc7dntm5t3NBEmbkW QvReT6l3gn1qL0IMcXnwNlSko3/KGp6J4r9/qnuwVGrn3dmb4AVtKi3jks75UvDzbkdR L3l7Z8RLofgEWYDAtPMtXifLU1v5T6Ub9JFVU= MIME-Version: 1.0 Received: by 10.68.14.97 with SMTP id o1mr28921308pbc.111.1321938833296; Mon, 21 Nov 2011 21:13:53 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.68.43.201 with HTTP; Mon, 21 Nov 2011 21:13:52 -0800 (PST) In-Reply-To: References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> <7D344AD5-B101-4BC1-8522-2259DB9853E4@castlepoint.net> Date: Tue, 22 Nov 2011 00:13:52 -0500 X-Google-Sender-Auth: Lb_Lwbt58QGLKVN1ulU6Z_7smrg Message-ID: From: Christopher Morrow To: Terry Manderson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] Route Leaks and BGP Security X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 05:13:58 -0000 On Mon, Nov 21, 2011 at 11:15 PM, Terry Manderson wrote: > > Speaking for myself on this one. > > On 22/11/2011, at 12:47 PM, Christopher Morrow wrote: >> >> ok, so if we step forward and ask for 'give me an attribute to >> indicate customer/peer/other', would we then trust that? it'd be >> (presumably) set per as-hop, is that anymore trustworthy than the >> communities supposed above? >> >> (I'd also ask what the rules are for setting this sort of thing, but I >> don't think that matters since we can't really trust the value in it) >> > > So lets say (hypothetically) we adopt a requirement of this system to all= ow a relying party to parse a route and know if it is intended or not by so= me construction of verifiable information. > 'if it is intended' ... means: a) "is intended to be seen at the vantage point it was observed at" (3 as-hops away) b) "with the as-path it shows up with" (isp1 - as1 - isp2 - me) c) something else? it's not clear what you meant, I'll assume b though... > I can't, for the life of me, see a transitive attribute _in_ BGP (signed = or otherwise) making a positive step in trying to secure intent of the loca= l AS as effected by a routing domain 2+ hops away. > err, this didn't parse for me :( You mean you don't see the possibility of adding a transitive attribute to BGP, which some AS adds to a path (and signs into the announcement, so it has to be kept along the path) and is replicated with each as-hop? Something like: isp1 - as1 - isp2 - me out:is-cust in:is-transit out:is-transit in:is-cust out:is-cust in:is-transit So, isp1 signs toward as1 "is-customer" as1 signs from isp1 "is-transit" as1 signs to isp2 "is-transit" isp2 signs from as1 "is-customer" isp2 signs to me "is-customer" me signs from isp2 "is-transit" Given that you'd have to configure (I suspect) each peering as 'peering' or 'transit' or 'customer' ...I don't see this flying either. :( I also don't see how to compute this on the local-router level either, given the information in the session, without an operator having to designate "this is a X" :( >>> >>> >> >> yup, I don't think we're going to get to the fully publicly exposed >> policy world though... are we? (we can't, I think, expect everyone to >> expose that sort of thing, never mind keep it updated) > > History tells us we are (for the most part) inept at doing so, even with = tools available. I had thought that RIPE had this licked in their region, no? they have policy-foo encoded in RPSL-stuff in the DB no? Is that NOT working for the cases in region? > But what we do know is that when policy is implemented, the results are t= ransparent and can be seen > (ris, routeviews, et al) by anyone who cares to look. > sure... but the data isn't exactly always 'accurate' there, and it's not accessible to the 'user' (router in the field) really, and I think the data includes lots of helter-skelter cruft that's not very helpful for this case :( >> >> yup... no-export/advertise were taken as 'advisory' communities that >> networks MAY heed, but certainly weren't bound to do so. >> >> So, back to the question: >> "Given BGP as it is today, how do you know if a route is a leak or not?" >> >> I suppose documenting: "One leak scenario is " is a fine >> thing, does it help to actually fix the problem though? I think what I >> heard in the meeting and on the thread(s) here was: "Sure leaks are >> important, there's not a way devised so far that distinguishes a >> 'leak' route from a 'normal' route, more than 1 as-hop from the >> 'source' of the leak. >> >> In the id/draft: >> >> =A0 isp1 =A0 isp2 - me >> =A0 =A0 =A0 \ =A0 =A0 / >> =A0 =A0 =A0 =A0AS1 >> >> I can't tell at 'me' that the route I see is a 'leak', just that I see >> an as-path that is isp1-as1-isp2. > > > The bit I think that is missing is some knowledge that isp1 asserts it ha= s valid routing through isp2, and any other potential 'true' paths. (noting= AS1 is considered the 'Serleena' here) > oh, I think danny's draft has a link between isp1/isp2 :( you probably meant here: "ISP1 and ISP2 directly connect, the path via AS1 is invalid/improper/a-leak" right? > From what I recall draft-huston-sidr-aao-profile takes a step in that dir= ection. (insert my reluctance about tightly binding routing operations to a= llocation practice) in such that it only publicises the valid paths, throug= h subsequent AAO's by by other ASNs. Thus if an AAO (in my reading) is crea= ted by isp1 with only an adjacency to isp2. It provides "me" with an abilit= y to say that the received route with AS1 on path is invalid. > > The AAO doesn't dive into local policy, and if isp1 has a private peering= with AS3, then it need not put that in an AAO and thus the business dealin= gs remain private - everything else ends up being seen in routeviews over t= ime. So this is one way... but not the only way. > > The killer problem here is that partial deployments will create path isla= nds, where only a number of the ASN hops have created AAO objects and thus = a path validity exercise will still fall into a potential leak trap until a= ll ASNs get there. The question then could then be, "is it o.k. for the ans= wer to route leaks to be near unusable until we have a significant deployme= nt" > note sure, is that time also when we'd have full resource-certification and the tools mostly available to just filter people reliably/properly/everywhere? ('everywhere' for some value of all-customers-of-all-isps, and maybe including settlement-free-interconnects as well?) -chris > Cheers, > T. > > From terry@terrym.net Mon Nov 21 21:52:25 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A510A1F0C9B for ; Mon, 21 Nov 2011 21:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrTpIzOh8OYy for ; Mon, 21 Nov 2011 21:52:24 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 85D1A1F0C7E for ; Mon, 21 Nov 2011 21:52:24 -0800 (PST) Received: by ggnp4 with SMTP id p4so915307ggn.31 for ; Mon, 21 Nov 2011 21:52:23 -0800 (PST) Received: by 10.236.128.167 with SMTP id f27mr10432248yhi.125.1321941142980; Mon, 21 Nov 2011 21:52:22 -0800 (PST) Received: from [192.168.1.105] (c114-77-161-74.fitzg3.qld.optusnet.com.au. [114.77.161.74]) by mx.google.com with ESMTPS id q5sm18042287yhm.7.2011.11.21.21.52.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Nov 2011 21:52:22 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Terry Manderson In-Reply-To: Date: Tue, 22 Nov 2011 15:52:16 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> <7D344AD5-B101-4BC1-8522-2259DB9853E4@castlepoint.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] Route Leaks and BGP Security X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 05:52:25 -0000 On 22/11/2011, at 3:13 PM, Christopher Morrow wrote: >=20 > 'if it is intended' ... means: > a) "is intended to be seen at the vantage point it was observed at" > (3 as-hops away) > b) "with the as-path it shows up with" (isp1 - as1 - isp2 - me) > c) something else? >=20 > it's not clear what you meant, I'll assume b though... >=20 to be specific, "it was intended to be seen at the vantage point it was = observed at, and in the form presented". So something showing up 3 hops away might be fine provided the 3 hops = are intended to be isp1 - as1 - isp2. >=20 > err, this didn't parse for me :( > You mean you don't see the possibility of adding a transitive > attribute to BGP, which some AS adds to a path (and signs into the > announcement, so it has to be kept along the path) and is replicated > with each as-hop? >=20 yes. (and sorry for being terse) > Something like: > isp1 - as1 - isp2 - me > out:is-cust in:is-transit out:is-transit in:is-cust out:is-cust > in:is-transit >=20 > So, isp1 signs toward as1 "is-customer" > as1 signs from isp1 "is-transit" >=20 > as1 signs to isp2 "is-transit" > isp2 signs from as1 "is-customer" >=20 the problem is that as1 can validly say "i don't do BGPSEC, but i'm = still a valid on path actor" and you have to trust that at face value = even though as1 is maleficent. You need isp1 to say that isp1 & as1 have = a valid transit arrangement. > isp2 signs to me "is-customer" > me signs from isp2 "is-transit" >=20 > Given that you'd have to configure (I suspect) each peering as > 'peering' or 'transit' or 'customer' ...I don't see this flying > either. :( I also don't see how to compute this on the local-router > level either, given the information in the session, without an > operator having to designate "this is a X" :( >=20 right. >>=20 >> History tells us we are (for the most part) inept at doing so, even = with tools available. >=20 > I had thought that RIPE had this licked in their region, no? they have > policy-foo encoded in RPSL-stuff in the DB no? Is that NOT working for > the cases in region? >=20 Probably they are the closest it gets, but a line from the ENISA paper = sticks with me: "Unfortunately, the quality of the IRRs varies, which makes it difficult = to rely on them" >> But what we do know is that when policy is implemented, the results = are transparent and can be seen >> (ris, routeviews, et al) by anyone who cares to look. >>=20 >=20 > sure... but the data isn't exactly always 'accurate' there, and it's > not accessible to the 'user' (router in the field) really, and I think > the data includes lots of helter-skelter cruft that's not very helpful > for this case :( I was simply using it to demonstrate that since transit routing = relationships end up in the RIS and routeviews as observable artefacts = (cruft included), advertising who you have a transit relationship in = something like the AAO isn't making any huge declarations of "I peer = with company X" that can't be found by other investigations. Although in hindsight the AAO might not be fine grained enough. In some = cases an autonomous system may want to optionally list a set of prefixes = that are subject to a transit/peer relationship with an adjacent AS.. = (and of course, in some cases not) >=20 > oh, I think danny's draft has a link between isp1/isp2 :( > you probably meant here: "ISP1 and ISP2 directly connect, the path via > AS1 is invalid/improper/a-leak" right? That was my understanding. >>=20 >>=20 >> The killer problem here is that partial deployments will create path = islands, where only a number of the ASN hops have created AAO objects = and thus a path validity exercise will still fall into a potential leak = trap until all ASNs get there. The question then could then be, "is it = o.k. for the answer to route leaks to be near unusable until we have a = significant deployment" >>=20 >=20 > note sure, is that time also when we'd have full > resource-certification and the tools mostly available to just filter > people reliably/properly/everywhere? ('everywhere' for some value of > all-customers-of-all-isps, and maybe including > settlement-free-interconnects as well?) >=20 That I don't know - crystal ball cracked when I tried to beat this = year's NHL results out of it. T. From christopher.morrow@gmail.com Mon Nov 21 22:09:49 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5BF21F8C63 for ; Mon, 21 Nov 2011 22:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.552 X-Spam-Level: X-Spam-Status: No, score=-103.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK2RvMfDEvZG for ; Mon, 21 Nov 2011 22:09:48 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9275521F8C5B for ; Mon, 21 Nov 2011 22:09:48 -0800 (PST) Received: by iaeo4 with SMTP id o4so9944734iae.31 for ; Mon, 21 Nov 2011 22:09:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=p7GukmY2c10ZjTkMoyZnCVqqugHc2km7Sqk/8C+tU9Q=; b=mO6ai721U9RyTcmoblOhNaEoBYKHpOkzusFGJaZwt87RnLv5w2zvPzRxvfmr2uJOxu kUvRi+Tn3tqE0iJAQv5J99lbCnQNXx0ZmWE+r7dWrFT597r9t8Z4wT8p1fxTFUlN1Jom NwJ7dhn5KvZhbz0kTEvSutvgOBsWxfuT+wang= MIME-Version: 1.0 Received: by 10.50.88.199 with SMTP id bi7mr17852334igb.45.1321942188020; Mon, 21 Nov 2011 22:09:48 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.231.207.78 with HTTP; Mon, 21 Nov 2011 22:09:17 -0800 (PST) In-Reply-To: References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> <7D344AD5-B101-4BC1-8522-2259DB9853E4@castlepoint.net> Date: Tue, 22 Nov 2011 01:09:17 -0500 X-Google-Sender-Auth: sNyHu4TW2wwaQSfk9Jaqz77vuSg Message-ID: From: Christopher Morrow To: Terry Manderson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] Route Leaks and BGP Security X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 06:09:49 -0000 On Tue, Nov 22, 2011 at 12:52 AM, Terry Manderson wrote: > > On 22/11/2011, at 3:13 PM, Christopher Morrow wrote: > >> >> 'if it is intended' ... means: >> =A0a) "is intended to be seen at the vantage point it was observed at" >> (3 as-hops away) >> =A0b) "with the as-path it shows up with" (isp1 - as1 - isp2 - me) >> =A0c) something else? >> >> it's not clear what you meant, I'll assume b though... >> > > to be specific, "it was intended to be seen at the vantage point it was o= bserved at, and in the form presented". > > So something showing up 3 hops away might be fine provided the 3 hops are= intended to be isp1 - as1 - isp2. ok >> >> err, this didn't parse for me :( >> You mean you don't see the possibility of adding a transitive >> attribute to BGP, which some AS adds to a path (and signs into the >> announcement, so it has to be kept along the path) and is replicated >> with each as-hop? >> > > yes. (and sorry for being terse) > > >> Something like: >> =A0isp1 =A0 =A0 =A0- =A0 =A0 =A0as1 =A0 =A0 =A0- =A0 =A0 =A0isp2 =A0 =A0= - =A0 me >> =A0 out:is-cust =A0in:is-transit out:is-transit in:is-cust =A0out:is-cus= t >> in:is-transit >> >> So, isp1 signs toward as1 "is-customer" >> =A0 =A0 =A0as1 signs from isp1 "is-transit" >> >> =A0 =A0 =A0as1 signs to isp2 "is-transit" >> =A0 =A0 =A0isp2 signs from as1 "is-customer" >> > > the problem is that as1 can validly say "i don't do BGPSEC, but i'm still= a valid on path actor" and you have to trust that at face value even thoug= h as1 is maleficent. You need isp1 to say that isp1 & as1 have a valid tran= sit arrangement. > right, if the attribute isn't signed (or maybe it flat doesn't exist without signage?) then ... we are where we are today. Once you cross out of signage, you are lost (under the bgpsec rules as written at least). >> =A0 =A0 =A0isp2 signs to me "is-customer" >> =A0 =A0 =A0me signs from isp2 "is-transit" >> >> Given that you'd have to configure (I suspect) each peering as >> 'peering' or 'transit' or 'customer' ...I don't see this flying >> either. :( I also don't see how to compute this on the local-router >> level either, given the information in the session, without an >> operator having to designate "this is a X" :( >> > > right. > >>> >>> History tells us we are (for the most part) inept at doing so, even wit= h tools available. >> >> I had thought that RIPE had this licked in their region, no? they have >> policy-foo encoded in RPSL-stuff in the DB no? Is that NOT working for >> the cases in region? >> > > Probably they are the closest it gets, but a line from the ENISA paper st= icks with me: > > "Unfortunately, the quality of the IRRs varies, which makes it difficult = to rely on them" > yup... well is that for RPSL/Policy-foo? or just for registration in genera= l? For instance, ALT-DB blows as a source for as701 data... RADB has some for AS701... Neither has RPSL-Policy-Foo for AS701 :( ('accepts all routes from && sends-all-routes to ') I got the impression that the culture in ripe-region essentially was that: "Everyone autogens filters from RIPE-IRR, so ... get that right or your internet is very small." > >>> But what we do know is that when policy is implemented, the results are= transparent and can be seen >>> (ris, routeviews, et al) by anyone who cares to look. >>> >> >> sure... but the data isn't exactly always 'accurate' there, and it's >> not accessible to the 'user' (router in the field) really, and I think >> the data includes lots of helter-skelter cruft that's not very helpful >> for this case :( > > I was simply using it to demonstrate that since transit routing relations= hips end up in the RIS and routeviews as observable artefacts (cruft includ= ed), advertising who you have a transit relationship in something like the = AAO isn't making any huge declarations of "I peer with company X" that can'= t be found by other investigations. > Could be, I do know that Randy's had some study time to show that even though people say: "Transit free" they aren't always as free as they'd like everyone to think. This wasn't (as I recall) observable from routeviews/ris data though :( Also, just using ris/routeviews as a starting point I was thinking: "Could you watch history and build a list of common adjacencies, or adjacencies you never expect to see?" I couldn't get to a reliable enough answer though :( (I didn't do any math though... or in-depth research, I fell back on 'well cyclops/et-al can't seem to be reliable 100% of the time, so...') It's fair to say that SOME transit routing relationships show up in RV/RIS, but not all do, and the vantage points are not 'all tier-1 and down', they are often 'tier-77 networks view of the world!' (with paths selected such that their Level3 transit is hidden for 'most' of the intertubes, is that because they only bought 3356-customer routes? or?? it's messy :( > Although in hindsight the AAO might not be fine grained enough. In some c= ases an autonomous system may want to optionally list a set of prefixes tha= t are subject to a transit/peer relationship with an adjacent AS.. (and of = course, in some cases not) > sure, the really weird relationships are ... weird. Also, very hard to quantify :( just dealing with the 'normal' cases seems to be weird though :( >> >> oh, I think danny's draft has a link between isp1/isp2 :( >> you probably meant here: "ISP1 and ISP2 directly connect, the path via >> AS1 is invalid/improper/a-leak" right? > > That was my understanding. > err, then a corrected ascii-art is: isp1 --- isp2 - me \ / as1 apologies for the mistake previously :( -chris >>> >>> >>> The killer problem here is that partial deployments will create path is= lands, where only a number of the ASN hops have created AAO objects and thu= s a path validity exercise will still fall into a potential leak trap until= all ASNs get there. The question then could then be, "is it o.k. for the a= nswer to route leaks to be near unusable until we have a significant deploy= ment" >>> >> >> note sure, is that time also when we'd have full >> resource-certification and the tools mostly available to just filter >> people reliably/properly/everywhere? ('everywhere' for some value of >> all-customers-of-all-isps, and maybe including >> settlement-free-interconnects as well?) >> > > That I don't know - crystal ball cracked when I tried to beat this year's= NHL results out of it. > > T. > > From danny@tcb.net Tue Nov 22 03:00:27 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E0E21F8D66 for ; Tue, 22 Nov 2011 03:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnRfTQW89NvE for ; Tue, 22 Nov 2011 03:00:27 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 560BE21F8D47 for ; Tue, 22 Nov 2011 03:00:27 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id CEFFC268063; Tue, 22 Nov 2011 04:00:26 -0700 (MST) Received: from dul1dmcphers-m1.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 22 Nov 2011 04:00:26 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=49377; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Tue, 22 Nov 2011 06:00:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> <7D344AD5-B101-4BC1-8522-2259DB9853E4@castlepoint.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] Route Leaks and BGP Security X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 11:00:28 -0000 On Nov 22, 2011, at 1:09 AM, Christopher Morrow wrote: >> Probably they are the closest it gets, but a line from the ENISA = paper sticks with me: >>=20 >> "Unfortunately, the quality of the IRRs varies, which makes it = difficult to rely on them" Terry: I think this is in large part attributed to lack of formally = verifiable IRR objects (i.e,.=20 objects bootstrapped by some resource certification mechanism). There = are many other reasons as well, I'm working with a few folks to try and capture some of = these.. > For instance, ALT-DB blows as a source for as701 data... RADB has some > for AS701... > Neither has RPSL-Policy-Foo for AS701 :( ('accepts all routes from > && sends-all-routes to > ') >=20 > I got the impression that the culture in ripe-region essentially was > that: "Everyone autogens filters from RIPE-IRR, so ... get that right > or your internet is very small." I like that culture, it provides accountability and puts the onus on = each operator=20 to maintain their information. -danny= From russw@riw.us Tue Nov 22 04:35:50 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1FF21F8DD4 for ; Tue, 22 Nov 2011 04:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0KKpIWFCgFa for ; Tue, 22 Nov 2011 04:35:49 -0800 (PST) Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 603E121F8DD0 for ; Tue, 22 Nov 2011 04:35:49 -0800 (PST) Received: from cpe-065-190-155-146.nc.res.rr.com ([65.190.155.146]:52363 helo=[192.168.100.52]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RSpZk-0007Qe-Dg for sidr@ietf.org; Tue, 22 Nov 2011 07:35:48 -0500 Message-ID: <4ECB971D.2090501@riw.us> Date: Tue, 22 Nov 2011 07:35:41 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> <7D344AD5-B101-4BC1-8522-2259DB9853E4@castlepoint.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us Subject: Re: [sidr] Route Leaks and BGP Security X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 12:35:50 -0000 > yup... no-export/advertise were taken as 'advisory' communities that > networks MAY heed, but certainly weren't bound to do so. >From what's been said on the list in the last several days, however, isn't it true that even the signatures are "advisory?" There is an insistence that local policy overrules the signatures --so all the entire SIDR effort is doing is providing more information on which to act. Why wouldn't signing communities be providing more information on which to act, as well? How can we say that providing more information on which to at is legitimate in the one case (that the receiver isn't bound by the information provided, but it is good information to have), and yet in the second case argue that because no-one is bound to act on the information, we shouldn't provide it? > I suppose documenting: "One leak scenario is " is a fine > thing, does it help to actually fix the problem though? I think what I > heard in the meeting and on the thread(s) here was: "Sure leaks are > important, there's not a way devised so far that distinguishes a > 'leak' route from a 'normal' route, more than 1 as-hop from the > 'source' of the leak. > > In the id/draft: > > isp1 isp2 - me > \ / > AS1 > > I can't tell at 'me' that the route I see is a 'leak', just that I see > an as-path that is isp1-as1-isp2. There is a way to tell --you simply have to have ISP1 and ISP2 advertise through some mechanism that AS1 is not a transit peer. You can either add this information into BGP itself, through a community or some other attribute --but note that BGP wasn't designed to do this, and you're trusting AS1 to pass along the information that's it's not a transit peer when trying to act as a transit peer (a bit pathological, IMHO), or you must do so out of band. There are out of band solutions available, but the insistence that no-one ever advertise their intent has blocked all such out of band options. Not everyone might object to advertising their intent --and building a system that doesn't allow the advertisement of policy to appease the few that do object appears to be backwards from the way business should be done. Operators should be given the ability to trade off between additional security and "privacy." :-) Russ From randy@psg.com Tue Nov 22 05:45:29 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9510421F8DFE for ; Tue, 22 Nov 2011 05:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBJbprxdEqqX for ; Tue, 22 Nov 2011 05:45:29 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1F59B21F8DE8 for ; Tue, 22 Nov 2011 05:45:29 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RSqf9-0008hw-ED; Tue, 22 Nov 2011 13:45:27 +0000 Date: Tue, 22 Nov 2011 15:45:24 +0200 Message-ID: From: Randy Bush To: Douglas Montgomery In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] Route Leak fix: V free routing X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 13:45:29 -0000 > These ideas have floated around for 20+ years. They have even appeared in > early BGP specs ... See "LINK TYPE" in http://www.ietf.org/rfc/rfc1105.txt. > > I actually think this is a useful idea, but the discussion always rat > holes in the supposition of absolute filtering rules and proof by counter > examples. > > I think it would be simple for transmitters to indicate and sign their > view of the peering relationship they are sending an update over. > Customer, provider, peer, or unspecified. > > (where/how you encode this is a detail, I would suggest in the PATH SIG > unless we decide to take on the more general approach below). > > What receivers do with that information ... Just like validation state, > would be a matter of local policy. > > Worse case is everyone chooses unspecified and we waste two bits under the > signature. > > Best case for those who don't care about declaring who their > customers/providers are to their customers/providers .... Then receivers > can choose to filter "V" routes if they wish. [ thanks for the only actual constructive hint i have seen on this list for a while. being still on travel and very time constrained, i have started just hitting delete to the repeat blather from the failed rpsec wg. ] do you expect it to be covered by the signature? if so, then the business relationship is published globally. do you see a way to assure veracity and non-repudiation while not exposing globally? randy From dougm@nist.gov Tue Nov 22 07:37:55 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D24821F8C95 for ; Tue, 22 Nov 2011 07:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTIjdmpPMFUm for ; Tue, 22 Nov 2011 07:37:53 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 742D321F85AE for ; Tue, 22 Nov 2011 07:37:53 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 22 Nov 2011 10:37:49 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 22 Nov 2011 10:37:18 -0500 From: "Montgomery, Douglas" To: Randy Bush Date: Tue, 22 Nov 2011 10:37:49 -0500 Thread-Topic: [sidr] Route Leak fix: V free routing Thread-Index: AcypLJ2felfbWIe0TdOcUxssLiD84g== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] Route Leak fix: V free routing X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 15:37:55 -0000 On 11/22/11 8:45 AM, "Randy Bush" wrote: >> These ideas have floated around for 20+ years. They have even appeared >>in >> early BGP specs ... See "LINK TYPE" in >>http://www.ietf.org/rfc/rfc1105.txt. >> >> I actually think this is a useful idea, but the discussion always rat >> holes in the supposition of absolute filtering rules and proof by >>counter >> examples. >> >> I think it would be simple for transmitters to indicate and sign their >> view of the peering relationship they are sending an update over. >> Customer, provider, peer, or unspecified. >> >> (where/how you encode this is a detail, I would suggest in the PATH SIG >> unless we decide to take on the more general approach below). >> >> What receivers do with that information ... Just like validation state, >> would be a matter of local policy. >> >> Worse case is everyone chooses unspecified and we waste two bits under >>the >> signature. >> >> Best case for those who don't care about declaring who their >> customers/providers are to their customers/providers .... Then receivers >> can choose to filter "V" routes if they wish. > >[ thanks for the only actual constructive hint i have seen on this list > for a while. being still on travel and very time constrained, i have > started just hitting delete to the repeat blather from the failed > rpsec wg. ] > >do you expect it to be covered by the signature? if so, then the >business relationship is published globally. do you see a way to assure >veracity and non-repudiation while not exposing globally? > >Randy I think the exposure thing is a red herring. Yes I expect it to be covered by a signature. It will travel by BGP as far as the update travels, to exactly the same set of players. So that set of folks already know you have a peering relationship, I suspect they can figure out what the effective relationship is, if they care, with a little analysis already. Of course collectors might capture the update ... Just as they do now revealing the peering existence. Concerned about that? I would like to understand how the exposure is any greater than just sending the update today? Still if you are concerned, set the relationship to "unspecified". It is just a low cost tool. I think one of our great mistakes is trying to engineering what the end use cases will be for some of these mechanisms. I contend we have little idea exactly how all of this will play out. Providing a low cost mechanism that would allow interested communities to address these forms of "leaks" .... especially if we don't mandate that everyone has to either (a) reveal the relationship (I.e., unspecified) or (B) enforce any policy relative to it (e.g., drop "V") ... Seems pretty harmless. If 20 years for now 99% of the peering hops in AS_PATHS are "unspecified" ... We hashed and extra byte for nothing ... A risk I would be willing to take. I will note that all previous attempts at this (there was another interim BGP spec years later that proposed a partial ordering among confederations that imposed similar no-"V" properties, I could not find a stable reference to that idea) suggested that it was an fixed property of the peering relationship. I will note that, so far, BGPSEC is 1 NLRI per update. While I am not suggesting sane reasons to do so, one might envision that some prefixes I might transmit with "unspecified" while others I might not. As far as veracity and non-repudiation .... I am setting a flag in an update, not attesting to a contract. The main (only?) use of which is to suggest that you don't want your customers to transit the Internet through you ... Nothing about that needs to be proved other than I set it. Maybe I see an emotional issue here ... What if the bits were call "no export to providers", "no export to peers", "unspecified", "free distribution"... i.e., this is not a declaration of a contractual status, it is a request by a transmitter to limit the distribution of an update potentially multi-hops down stream. I set this if I care, or think it would be a public service, to constrain the flow of this update. Mind you this naming conveys that it is the transmitter who is trying to effect policy, not the receiver. The difference in having this under the PATH SIG is my preferences remain with the update, unless someone strips the whole sig. Once again, if receivers care about any of this, they would write policies to implement their concerns ... Just as they will have to to react to the validation state itself. dougm > From jakob.heitz@ericsson.com Tue Nov 22 08:16:35 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D87621F8C88 for ; Tue, 22 Nov 2011 08:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.406 X-Spam-Level: X-Spam-Status: No, score=-6.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dE0X4Bu4wntc for ; Tue, 22 Nov 2011 08:16:35 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0362121F8C86 for ; Tue, 22 Nov 2011 08:16:34 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAMGGTYm020545; Tue, 22 Nov 2011 10:16:30 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 22 Nov 2011 11:16:26 -0500 From: Jakob Heitz To: Brian Dickson Date: Tue, 22 Nov 2011 11:17:23 -0500 Thread-Topic: [sidr] Burstiness of BGP updates Thread-Index: AcypMhWb8R06/qQkSpCgmdP5xusnnw== Message-ID: <9DD48837-1291-48AA-BD9B-815A22CC010B@ericsson.com> References: <7309FCBCAE981B43ABBE69B31C8D21391A45A1F85D@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FE9F@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D21391A45A1FEC8@EUSAACMS0701.eamcs.ericsson.se> <4EC3125D.4000309@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2061F@EUSAACMS0701.eamcs.ericsson.se> <4EC329C6.4090600@riw.us> <7309FCBCAE981B43ABBE69B31C8D21391A45A2062E@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] Burstiness of BGP updates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 16:16:35 -0000 > Basically, if you have BGPsec enabled with a given peer, you might get > a combination of signed and unsigned from that peer - but for a given pre= fix, > you MUST only get one or the other. Invalid-sig !=3D unsigned. >=20 > Accepting unsigned as a "fast" short-cut is insane, frankly. Why? BGPSEC does not prevent route leaks (MITM) BGPSEC does not prevent intercept BGPSEC is not a panacea From brian.peter.dickson@gmail.com Tue Nov 22 08:50:53 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59B91F0C3D for ; Tue, 22 Nov 2011 08:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llo3aBzGJTIi for ; Tue, 22 Nov 2011 08:50:53 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 382A01F0C3C for ; Tue, 22 Nov 2011 08:50:52 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so43570bkb.31 for ; Tue, 22 Nov 2011 08:50:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1xYS+B+ZqylrflcV06//5Pb2+jHv6y5cvmWErBV99k8=; b=Ksk+Mr9Od0SoIvHJEodiOt1118atJEPQ/kEJDV9U8lP3hB1o1dTgO0qQ7Xw9qQ9oEE t+RFDttr6asiiBxC0h76s85IQoC4UZbgzlN9hWEL5+vT7vVhaArnStXxSQF+6rQbL32H jo1s0c/Hett94t5VcuEmhszJ/noHFV9bkVppM= MIME-Version: 1.0 Received: by 10.204.0.82 with SMTP id 18mr2009859bka.86.1321980648483; Tue, 22 Nov 2011 08:50:48 -0800 (PST) Received: by 10.223.143.8 with HTTP; Tue, 22 Nov 2011 08:50:48 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Nov 2011 11:50:48 -0500 Message-ID: From: Brian Dickson To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] Route Leak fix: V free routing X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 16:50:53 -0000 On Tue, Nov 22, 2011 at 8:45 AM, Randy Bush wrote: > > do you expect it to be covered by the signature? =A0if so, then the > business relationship is published globally. =A0do you see a way to assur= e > veracity and non-repudiation while not exposing globally? I see a way... [I'm assuming here, that the the places where business relation ships need to be possible to hide, are only where there is the potential for that hiding to have some effect: - Transit providers know the relationship they have with their customers, and their customers' customers... - Peers expect to only hear their peers' customers (and customers' customer= s) - (Leaving aside "special" arrangements) - The only place where any announcement of non-customer routes occurs is from transit to customer end assumption] What is needed, is a separate signature chain, "provenance". The provenance chain is required ONLY when sending a customer prefix to a non-customer. The provenance chain consists of signatures over (the current "apex" bit + previous signature) The apex bit is either zero (on customer->transit AS path hops), or one (peer->peer). Once received from a peer or transit provider, and validated (if present), the provenance chain MAY be stripped from the prefix. If a prefix has no provenance chain, it is to be treated as if it has at least one apex bit set. Transit providers SHOULD reject any prefix from a customer, if any "apex" bit is set (or if there is no provenance chain). Peers SHOULD reject a prefix from a peer, which has no provenance chain, or has a provenance chain with the "apex" bit set anywhere except on the peers' entry on the chain. Note that the vast majority of prefixes received by any AS, will be non-customers' and can have their provenance chains removed. This significantly reduces the impact of another set of signatures. The absence of a provenance chain achieves the hiding of business relations= hips. The absence of a provenance chain also permits the receiver of routes to detect and stop leaked prefixes. This mechanism would be applied on a prefix basis, not blindly on an neighbor AS basis, although it would require knowledge of the relationship with the neighbor to function correctly. I think this meets all Randy's requirements, as well as Danny's. Brian From jakob.heitz@ericsson.com Tue Nov 22 09:10:25 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4BF21F8C4E for ; Tue, 22 Nov 2011 09:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ABDk5yhS1uT for ; Tue, 22 Nov 2011 09:10:23 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id B2AAC21F8C4F for ; Tue, 22 Nov 2011 09:10:18 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAMHA9JK002017; Tue, 22 Nov 2011 11:10:14 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 22 Nov 2011 12:10:08 -0500 From: Jakob Heitz To: Brian Dickson Date: Tue, 22 Nov 2011 12:11:04 -0500 Thread-Topic: [sidr] Route Leak fix: V free routing Thread-Index: AcypOZWOZyuUrp69Rv+bh5C3PX+aKQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] Route Leak fix: V free routing X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 17:10:25 -0000 That's like making the British drive on the right: you can not incrementall= y deploy. -- Jakob Heitz. On Nov 22, 2011, at 8:51 AM, "Brian Dickson" wrote: > On Tue, Nov 22, 2011 at 8:45 AM, Randy Bush wrote: >=20 >>=20 >> do you expect it to be covered by the signature? if so, then the >> business relationship is published globally. do you see a way to assure >> veracity and non-repudiation while not exposing globally? >=20 > I see a way... >=20 > [I'm assuming here, that the the places where business relation ships > need to be possible to hide, are only where there is the potential for > that hiding to have some effect: >=20 > - Transit providers know the relationship they have with their > customers, and their customers' customers... > - Peers expect to only hear their peers' customers (and customers' custom= ers) > - (Leaving aside "special" arrangements) > - The only place where any announcement of non-customer routes occurs > is from transit to customer >=20 > end assumption] >=20 > What is needed, is a separate signature chain, "provenance". >=20 > The provenance chain is required ONLY when sending a customer prefix > to a non-customer. >=20 > The provenance chain consists of signatures over (the current "apex" > bit + previous signature) > The apex bit is either zero (on customer->transit AS path hops), or > one (peer->peer). >=20 > Once received from a peer or transit provider, and validated (if > present), the provenance chain MAY be stripped from the prefix. >=20 > If a prefix has no provenance chain, it is to be treated as if it has > at least one apex bit set. >=20 > Transit providers SHOULD reject any prefix from a customer, if any > "apex" bit is set (or if there is no provenance chain). >=20 > Peers SHOULD reject a prefix from a peer, which has no provenance > chain, or has a provenance chain with the "apex" bit set anywhere > except on the peers' entry on the chain. >=20 > Note that the vast majority of prefixes received by any AS, will be > non-customers' and can have their provenance chains removed. This > significantly reduces the impact of another set of signatures. >=20 > The absence of a provenance chain achieves the hiding of business relatio= nships. >=20 > The absence of a provenance chain also permits the receiver of routes > to detect and stop leaked prefixes. >=20 > This mechanism would be applied on a prefix basis, not blindly on an > neighbor AS basis, although it would require knowledge of the > relationship with the neighbor to function correctly. >=20 > I think this meets all Randy's requirements, as well as Danny's. >=20 > Brian > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From brian.peter.dickson@gmail.com Tue Nov 22 09:17:08 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811E321F8C57 for ; Tue, 22 Nov 2011 09:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1ptPLyM0P4Y for ; Tue, 22 Nov 2011 09:17:08 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A764121F8C54 for ; Tue, 22 Nov 2011 09:17:07 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so77424bkb.31 for ; Tue, 22 Nov 2011 09:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3s8pRbZMlWK4zk78Thp32L+0+Hz0HCW7v7uiH/aHyaU=; b=j0SAGII6y3moSslqoG5tgbBjA0XFFOea24aibRSz3hTOGrXLR7z+oSZ/OqO38805+W G5ljClhX33X/hEiVuIr9iKP/5I41yeuIGiwUBxHObHSTRyq0ppTVEFhdFny8xiKaXZHd i8+ED9cocH4zATEsMArvQQwIrLQZYXdkO9Hzc= MIME-Version: 1.0 Received: by 10.204.154.25 with SMTP id m25mr19730268bkw.140.1321982226775; Tue, 22 Nov 2011 09:17:06 -0800 (PST) Received: by 10.223.143.8 with HTTP; Tue, 22 Nov 2011 09:17:06 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Nov 2011 12:17:06 -0500 Message-ID: From: Brian Dickson To: Jakob Heitz Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] Route Leak fix: V free routing X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 17:17:08 -0000 On Tue, Nov 22, 2011 at 12:11 PM, Jakob Heitz wrote: > That's like making the British drive on the right: you can not incrementally deploy. I don't understand your comment - can you be more specific and precise? What can you not deploy incrementally? BGPsec? An end-to-end BGPsec secured path? Or are you talking about adding this to the spec - clearly this would be incompatible with BGPsec implementations that didn't have it. If the latter, note: the deployed set is currently the null set, so your argument is moot. Brian From jakob.heitz@ericsson.com Tue Nov 22 10:02:21 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249BF1F0C38 for ; Tue, 22 Nov 2011 10:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.417 X-Spam-Level: X-Spam-Status: No, score=-6.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IapWAWlphmg9 for ; Tue, 22 Nov 2011 10:02:20 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 94CAF1F0C35 for ; Tue, 22 Nov 2011 10:02:20 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAMI2F44015079; Tue, 22 Nov 2011 12:02:18 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 22 Nov 2011 13:02:13 -0500 From: Jakob Heitz To: Brian Dickson Date: Tue, 22 Nov 2011 13:02:11 -0500 Thread-Topic: [sidr] Route Leak fix: V free routing Thread-Index: AcypOpAtWrRtDwSwS0i9By2Py4lHfQABRmrg Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391A47045B49@EUSAACMS0701.eamcs.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] Route Leak fix: V free routing X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 18:02:21 -0000 I stand corrected. Good idea. If I understand it right, the presence of a BGPSEC signature AND the absence of a provenance signature signals that the prefix has left the set of AS's that are contracted to provide it reachability. -- Jakob Heitz. > -----Original Message----- > From: Brian Dickson [mailto:brian.peter.dickson@gmail.com] > Sent: Tuesday, November 22, 2011 9:17 AM > To: Jakob Heitz > Cc: sidr wg list > Subject: Re: [sidr] Route Leak fix: V free routing >=20 > On Tue, Nov 22, 2011 at 12:11 PM, Jakob Heitz > wrote: > > That's like making the British drive on the right: you can not > incrementally deploy. >=20 > I don't understand your comment - can you be more specific and > precise? >=20 > What can you not deploy incrementally? >=20 > BGPsec? An end-to-end BGPsec secured path? >=20 > Or are you talking about adding this to the spec - clearly this > would be incompatible with BGPsec implementations that didn't have > it. >=20 > If the latter, note: the deployed set is currently the null set, so > your argument is moot. >=20 > Brian From christopher.morrow@gmail.com Tue Nov 22 13:12:58 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD8E1F0C47 for ; Tue, 22 Nov 2011 13:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.554 X-Spam-Level: X-Spam-Status: No, score=-103.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAERgyoWxCkS for ; Tue, 22 Nov 2011 13:12:58 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E54571F0C35 for ; Tue, 22 Nov 2011 13:12:57 -0800 (PST) Received: by iaeo4 with SMTP id o4so822572iae.31 for ; Tue, 22 Nov 2011 13:12:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=is9aixeNzqHHudMRi6GEzqUWkBU/Cv0EDxmKJfr1tAk=; b=UDmSnFt+/IVpXbZ6216EKWlSNcdwXMRj+2oKHTsMo5Rbb5DwFcK+DYlMwPIwTIP4Jx ICvjQ23mPHCyROOCtqeq0ZaugSKwiN+HUDY/Q655NvcvQlFlioQWzfSZR+9mHkyMjFVw 1vsc9e60NEIbs9aAGCtasrOaKkU5XatYLGoM4= MIME-Version: 1.0 Received: by 10.231.27.203 with SMTP id j11mr5718083ibc.10.1321996377509; Tue, 22 Nov 2011 13:12:57 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.231.207.78 with HTTP; Tue, 22 Nov 2011 13:12:57 -0800 (PST) In-Reply-To: <4ECB971D.2090501@riw.us> References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> <7D344AD5-B101-4BC1-8522-2259DB9853E4@castlepoint.net> <4ECB971D.2090501@riw.us> Date: Tue, 22 Nov 2011 16:12:57 -0500 X-Google-Sender-Auth: k2Pm1WZFm364fPTmKymtAlvyORU Message-ID: From: Christopher Morrow To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] Route Leaks and BGP Security X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 21:12:58 -0000 On Tue, Nov 22, 2011 at 7:35 AM, Russ White wrote: > >> yup... no-export/advertise were taken as 'advisory' communities that >> networks MAY heed, but certainly weren't bound to do so. > > From what's been said on the list in the last several days, however, > isn't it true that even the signatures are "advisory?" There is an in the end state I think we'd like them to be mandatory. If they aren't there then the operator of the network in question can decide to accept/depref/deny the route in question. > insistence that local policy overrules the signatures --so all the > entire SIDR effort is doing is providing more information on which to act= . sure. > Why wouldn't signing communities be providing more information on which > to act, as well? How can we say that providing more information on which If communities were guaranteed to exist along the entire path, maybe? If people didn't add communities and drop them 'at will' maybe? If we understood what a community meant, maybe? I don't see any of the three things there being the case though :( Communities are really only useful inside a single AS or to the direct peers (where they signal ala RFC1998 action to be taken on the peer network). > to at is legitimate in the one case (that the receiver isn't bound by > the information provided, but it is good information to have), and yet > in the second case argue that because no-one is bound to act on the > information, we shouldn't provide it? > >> I suppose documenting: "One leak scenario is " is a fine >> thing, does it help to actually fix the problem though? I think what I >> heard in the meeting and on the thread(s) here was: "Sure leaks are >> important, there's not a way devised so far that distinguishes a >> 'leak' route from a 'normal' route, more than 1 as-hop from the >> 'source' of the leak. >> >> In the id/draft: >> >> =A0 =A0isp1 =A0 isp2 - me >> =A0 =A0 =A0 =A0\ =A0 =A0 / >> =A0 =A0 =A0 =A0 AS1 >> >> I can't tell at 'me' that the route I see is a 'leak', just that I see >> an as-path that is isp1-as1-isp2. > > There is a way to tell --you simply have to have ISP1 and ISP2 advertise > through some mechanism that AS1 is not a transit peer. You can either > add this information into BGP itself, through a community or some other > attribute --but note that BGP wasn't designed to do this, and you're > trusting AS1 to pass along the information that's it's not a transit > peer when trying to act as a transit peer (a bit pathological, IMHO), or > you must do so out of band. right, this was the focus of at least 2 messages I sent over the last few days, it's also a focus of Brian Dickson's notes... 'add a bit to bgp, flip it up/down if customer/peer'. I don't see a practical (and trustworthy) method to do that though. -chris > There are out of band solutions available, but the insistence that > no-one ever advertise their intent has blocked all such out of band optio= ns. > > Not everyone might object to advertising their intent --and building a > system that doesn't allow the advertisement of policy to appease the few > that do object appears to be backwards from the way business should be > done. Operators should be given the ability to trade off between > additional security and "privacy." > > :-) > > Russ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From brian.peter.dickson@gmail.com Tue Nov 22 15:18:14 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1976211E80C1 for ; Tue, 22 Nov 2011 15:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHUe5iSieoSA for ; Tue, 22 Nov 2011 15:18:13 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6D411E80BA for ; Tue, 22 Nov 2011 15:18:13 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so471730bkb.31 for ; Tue, 22 Nov 2011 15:18:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qiRCN8deu9xX7nYcPbbWnsh6SO3FwgSS82/3jXt9kz4=; b=AyqDPG3A2cNdWZpW5jzVKoANbXEzW7KYeNCYR5zKvGZJtTSrjlKzUa6YhqBmm4HmeL KxU8JxJgPNzWNyBqNzEeDItS2VpC0RfwXONuEioo8CgG8tyVMla8EJ6/60urfrb2VBld a6v9ZOik9b1fpVgarT52R5kJ1PRojwc4QNFcM= MIME-Version: 1.0 Received: by 10.204.128.208 with SMTP id l16mr1493337bks.14.1322003892355; Tue, 22 Nov 2011 15:18:12 -0800 (PST) Received: by 10.223.143.8 with HTTP; Tue, 22 Nov 2011 15:18:12 -0800 (PST) In-Reply-To: References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> <7D344AD5-B101-4BC1-8522-2259DB9853E4@castlepoint.net> <4ECB971D.2090501@riw.us> Date: Tue, 22 Nov 2011 18:18:12 -0500 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] Route Leaks and BGP Security X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 23:18:14 -0000 On Tue, Nov 22, 2011 at 4:12 PM, Christopher Morrow wrote: > On Tue, Nov 22, 2011 at 7:35 AM, Russ White wrote: >> insistence that local policy overrules the signatures --so all the >> entire SIDR effort is doing is providing more information on which to act. > > sure. > >> Why wouldn't signing communities be providing more information on which >> to act, as well? How can we say that providing more information on which > > If communities were guaranteed to exist along the entire path, maybe? > If people didn't add communities and drop them 'at will' maybe? If we > understood what a community meant, maybe? > > I don't see any of the three things there being the case though :( > Communities are really only useful inside a single AS or to the direct > peers (where they signal ala RFC1998 action to be taken on the peer > network). I've been thinking about ways to handle additional attributes to the set of things signed, while also allowing some of those to be added/changed/deleted along the way. I'll be working on a more formal message (or possibly draft), but wanted to at least get the idea in folks' heads, that it isn't impossible, and might even be workable. The simplest case is, the extra values get added to the signature block of the originator, and nobody modifies those values along the way. (Obviously there are some attributes where this is not possible because BGP requires them to change.) [In this simple case, nothing new is really needed.] The problem happens the first time you change something, and gets worse with every change. The idea I'm working on, is to create a "stack" of attributes that change. This is very much like the stack in a language like 'C'. The current values are kept in the normal place in BGP. The immediately previous value(s) that were replaced (or deleted) are pushed onto the top of the stack, as well as some kind of indicator of what attributes were added, changed, and deleted, and which entry in the AS_path these correspond to. (Maybe a NULL indicator as a placeholder if nothing changed...) Signature validation required a reverse-diff be applied while working backwards through the signatures. The set of additional signed attributes gets reconstituted, and combined into some canonical form for validating the signature. It's clunky, for sure, and for attributes that are high-volume and subject to lots of change along an AS-path, might bloat things a bit. On the other hand, it provides data not previously available for path selection, along with crypto validation of that data. Comments on this idea are welcome. It's a work in progress.... Brian From kent@bbn.com Mon Nov 28 14:13:13 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DAA11E8125 for ; Mon, 28 Nov 2011 14:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.999 X-Spam-Level: X-Spam-Status: No, score=-104.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXz-xW1KPi8h for ; Mon, 28 Nov 2011 14:13:13 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 510FA11E80A6 for ; Mon, 28 Nov 2011 14:13:13 -0800 (PST) Received: from dhcp89-089-006.bbn.com ([128.89.89.6]:49201) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RV9Ro-0009w5-Ey; Mon, 28 Nov 2011 17:13:12 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <72E12AD7-CFAF-4FBD-8A98-F93038F7E8FB@tcb.net> References: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> <72E12AD7-CFAF-4FBD-8A98-F93038F7E8FB@tcb.net> Date: Mon, 28 Nov 2011 17:13:10 -0500 To: Danny McPherson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Origin Ops, TALs and Local TAs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 22:13:13 -0000 At 10:09 PM -0500 11/21/11, Danny McPherson wrote: >... > > I don't understand all of the words above. > >Apologies for the loose terminology here.. Try this.. > >AS1 --- ISP1 (AS2) --- ISP2 (AS3) --- AS4 > >In the case of LTA if these four parties wish to transact their >constraints files >(or shared "non-putative" RPKI TAs) must be familiar and synchronized with >each other via some out of band mechanism - i.e., they either have to: > >1) synchronize LTA contents across the set >2) share a common non-putative TA that magically does this > >and in doing so, they likely would want to constrain what a TA is allowed to >assert, via a constraints file, as noted above? > >That is, LTA for the local AS doesn't fix the multi-AS/multi-administrator/RP >issue, and so some synchronization or shared non-putative TA needs to be >developed in they desire autonomy outside of the putative set. > >Is that correct? The original model for an LTA was, as the name suggests, local, hence just one AS. However, it is easy to extend that model to encompass a set of AS'es under the same admin control. In that case, the set of ASes all agree to accept the RPKI "view" managed by some entity in control (relative to the set of ASes). In your example are all of the ASes independent? You say that they want to "transact their constraints file" but you didn't say why, nor what the relationships might be among the constraints file for each AS. The LTA constraints, as currently defined, are expressed via a set of local processing flags, tags, and pointers (via SKIs) to extant certs (sections 3.2-3.4). All of these can be shared, but that doesn't say what each AS would do if the values of the flags or tags differ. Since I'm not sure what the trust model is here, I don't know if this is a problem. Also, if the blocks subsection has conflicting directions it's not clear what each AS should do. (A union of the constraints would work cleanly, but only if the affected subtrees are disjoint. Other attempts at forming a union of constraints could break, depending on the details.) Modulo the issue of constraint conflicts, each AS can maintain its own LTA, and perform the re-parenting and "perforation" as directed by the blocks subsection of the constraints. Does that answer your question? Steve From christopher.morrow@gmail.com Mon Nov 28 16:53:16 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C721F0C58 for ; Mon, 28 Nov 2011 16:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IaLgy8P16oY for ; Mon, 28 Nov 2011 16:53:15 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB10D1F0C46 for ; Mon, 28 Nov 2011 16:53:15 -0800 (PST) Received: by iaeo4 with SMTP id o4so11634472iae.31 for ; Mon, 28 Nov 2011 16:53:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0UZZZZG4qc2MRQk/SL2oT42xP6U6PnOPQkvnLs8DCfc=; b=HXHXwTCOjCU2QEKLZMt4tgWNZvliBvhz6vQk3hkolGFt89rwD0nZnNGB/gCcLpsV/R 42CMQYEGHWjsnXLS/V4bEN6kzIEsi2AwuG+LOjhJrjoAgquxXdCeY4ngSUBsS9I5j9dP 4OM17go3lLJ0qJ4cTp/0WTPvhhMbU8vntWWos= MIME-Version: 1.0 Received: by 10.50.88.199 with SMTP id bi7mr52579689igb.45.1322527995394; Mon, 28 Nov 2011 16:53:15 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.231.207.78 with HTTP; Mon, 28 Nov 2011 16:53:15 -0800 (PST) In-Reply-To: References: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> <72E12AD7-CFAF-4FBD-8A98-F93038F7E8FB@tcb.net> Date: Mon, 28 Nov 2011 19:53:15 -0500 X-Google-Sender-Auth: G9RnBPOYhlKwxct8khy7_FgzxEA Message-ID: From: Christopher Morrow To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr@ietf.org Subject: Re: [sidr] Origin Ops, TALs and Local TAs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 00:53:16 -0000 On Mon, Nov 28, 2011 at 5:13 PM, Stephen Kent wrote: > At 10:09 PM -0500 11/21/11, Danny McPherson wrote: >> >> ... >> =A0> I don't understand all of the words above. >> >> Apologies for the loose terminology here.. =A0Try this.. >> >> AS1 --- ISP1 (AS2) --- ISP2 (AS3) --- AS4 >> >> In the case of LTA if these four parties wish to transact their >> constraints files >> (or shared "non-putative" RPKI TAs) must be familiar and synchronized wi= th >> each other via some out of band mechanism - i.e., they either have to: >> >> 1) synchronize LTA contents across the set >> 2) share a common non-putative TA that magically does this >> >> and in doing so, they likely would want to constrain what a TA is allowe= d >> to >> assert, =A0via a constraints file, as noted above? >> >> That is, LTA for the local AS doesn't fix the >> multi-AS/multi-administrator/RP >> issue, and so some synchronization or shared non-putative TA needs to be >> developed in they desire autonomy outside of the putative set. >> Is that correct? > > The original model for an LTA was, as the name suggests, local, hence jus= t > one AS. =A0However, it is easy to extend that model to encompass a set of > AS'es under the same admin control. In that case, the set of ASes all agr= ee > to accept the > RPKI "view" managed by some entity in control (relative to the set of ASe= s). > > In your example are all of the ASes independent? You say that they want t= o > "transact their constraints file" but you didn't say why, nor what the > relationships might be among the constraints file for each AS. I think danny's example (as explained off-line in taipei) was something lik= e: o 3 cooperating ASNs (say: 701, 7018, 2914) o one customer on either side of the 3 ASNs (a-widget-maker && a-widget-user/customer) o All have RPKI + BGPSEC deployed o the 'blackhelicopters of forgotten payment' arrive at ARIN's doorstep and remove the Registration data for a-root/24. For a-widget-customer to still access a-widget-maker all of the intermediate ASN's (and a-widget-customer even) will have to enter into their LTA's some bogus/temporary certificate data... Or, I suppose, they could just wing it on 'not validated' but still the only prefix-in-town? I think Danny's proposing some federation of LTAs under distributed control where these folks all agree that "a-widget-maker/24 is still a-ok by us!". -chris From kent@bbn.com Tue Nov 29 07:31:48 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15A11F0C38 for ; Tue, 29 Nov 2011 07:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.799 X-Spam-Level: X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irYhEI0pNJUh for ; Tue, 29 Nov 2011 07:31:48 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2A18321F8C3D for ; Tue, 29 Nov 2011 07:31:48 -0800 (PST) Received: from dhcp89-089-006.bbn.com ([128.89.89.6]:49162) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RVPes-000Ixv-6o; Tue, 29 Nov 2011 10:31:46 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> <72E12AD7-CFAF-4FBD-8A98-F93038F7E8FB@tcb.net> Date: Tue, 29 Nov 2011 10:27:48 -0500 To: Christopher Morrow From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Origin Ops, TALs and Local TAs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 15:31:48 -0000 At 7:53 PM -0500 11/28/11, Christopher Morrow wrote: >... > >I think danny's example (as explained off-line in taipei) was something like: > > o 3 cooperating ASNs (say: 701, 7018, 2914) > o one customer on either side of the 3 ASNs (a-widget-maker && >a-widget-user/customer) > o All have RPKI + BGPSEC deployed > o the 'blackhelicopters of forgotten payment' arrive at ARIN's >doorstep and remove the Registration data for a-root/24. > > For a-widget-customer to still access a-widget-maker all of the >intermediate ASN's (and a-widget-customer even) will have to enter >into their LTA's some bogus/temporary certificate data... Or, I >suppose, they could just wing it on 'not validated' but still the only >prefix-in-town? > >I think Danny's proposing some federation of LTAs under distributed >control where these folks all agree that "a-widget-maker/24 is still >a-ok by us!". > >-chris OK, that's a very helpful statement of the concern. If the widget maker had a cert for the /24, the LTA management mechanisms can allow the co-operating ASes to continue to use it, even after an RIR removes it. The current spec assumes that the ASes retrieve the old cert from their local caches to do this. We might explore (standard) ways to move certs to deal with the possibility that one or more of the ASes in question does not have the old cert in its cache. There are controls to allow RPs to ignore the expiration of the certs for the widget maker, but that's not the best outcome. Ultimately the widget maker would like to have a new CA cert issued to it, and continue to manage the' corresponding CRL, manifest, and ROA(s). All of that can be accommodated using the LTA mechanisms, but it will become complex if there are a lot of exceptions of this sort. Steve From christopher.morrow@gmail.com Tue Nov 29 07:36:28 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1891F0C46 for ; Tue, 29 Nov 2011 07:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dR9-9ZGuqEfP for ; Tue, 29 Nov 2011 07:36:27 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7306221F8C3F for ; Tue, 29 Nov 2011 07:36:27 -0800 (PST) Received: by ggnp4 with SMTP id p4so8039945ggn.31 for ; Tue, 29 Nov 2011 07:36:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/5Gu9vXh8ldqpzXkw8seslVBQkJ/C+XLK3bnQfJoCUc=; b=NK/4l0ieQff5gigNb5JmmKnS1wPfmqNb5GWSJGOJHZ0nSiHTOIzpy4bw06VFjkF5tR 76nCdfQfWpyeg3NFCCH0Zic8KaRWQwP8tVCdUpRdhEkJX1TCY7hH8VOoaR+Ru/timdyV CHyPQKpsOlyxPHRAdO5gnwQoygPs0XT5jttGo= MIME-Version: 1.0 Received: by 10.50.104.137 with SMTP id ge9mr55639144igb.38.1322580986763; Tue, 29 Nov 2011 07:36:26 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.231.207.78 with HTTP; Tue, 29 Nov 2011 07:36:26 -0800 (PST) In-Reply-To: References: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> <72E12AD7-CFAF-4FBD-8A98-F93038F7E8FB@tcb.net> Date: Tue, 29 Nov 2011 10:36:26 -0500 X-Google-Sender-Auth: UdnVUiwkPnDNIiU_STimRQyaqPE Message-ID: From: Christopher Morrow To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org Subject: Re: [sidr] Origin Ops, TALs and Local TAs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 15:36:28 -0000 On Tue, Nov 29, 2011 at 10:27 AM, Stephen Kent wrote: > There are controls to allow RPs to ignore the expiration of the certs for > the widget maker, but that's not the best outcome. Ultimately the widget > maker > would like to have a new CA cert issued to it, and continue to manage the' > corresponding CRL, manifest, and ROA(s). All of that can be accommodated > using the LTA mechanisms, but it will become complex if there are a lot of > exceptions of this sort. I think this last bit gets at danny's concern (after the 'but every asn in the path has to agree that the root is wrong' bit)... lots more complexity here is not helpful :( -chris From danny@tcb.net Tue Nov 29 07:49:40 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C515821F8C7A for ; Tue, 29 Nov 2011 07:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ieZNLc6bJMP for ; Tue, 29 Nov 2011 07:49:40 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 6078021F8C7B for ; Tue, 29 Nov 2011 07:49:40 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 1A38B3681BA; Tue, 29 Nov 2011 08:49:40 -0700 (MST) Received: from new-host-5.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 29 Nov 2011 08:49:40 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=59601; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Danny McPherson In-Reply-To: Date: Tue, 29 Nov 2011 10:49:24 -0500 Content-Transfer-Encoding: 7bit Message-Id: <60D433F0-D9E5-428E-8A79-47EE5E1CECFE@tcb.net> References: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> <72E12AD7-CFAF-4FBD-8A98-F93038F7E8FB@tcb.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1251.1) Cc: sidr@ietf.org Subject: Re: [sidr] Origin Ops, TALs and Local TAs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 15:49:40 -0000 On Nov 29, 2011, at 10:36 AM, Christopher Morrow wrote: > I think this last bit gets at danny's concern (after the 'but every > asn in the path has to agree that the root is wrong' bit)... lots more > complexity here is not helpful :( Yes. -danny From kent@bbn.com Tue Nov 29 08:27:19 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81A821F8C47 for ; Tue, 29 Nov 2011 08:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.066 X-Spam-Level: X-Spam-Status: No, score=-106.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UR6aX8Ddw-yS for ; Tue, 29 Nov 2011 08:27:19 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 620E021F8C3A for ; Tue, 29 Nov 2011 08:27:19 -0800 (PST) Received: from dhcp89-089-006.bbn.com ([128.89.89.6]:49165) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RVQWb-000KHW-OD; Tue, 29 Nov 2011 11:27:17 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <60D433F0-D9E5-428E-8A79-47EE5E1CECFE@tcb.net> References: <80D9C12A-354E-4A90-8E97-946519E499D0@tcb.net> <72E12AD7-CFAF-4FBD-8A98-F93038F7E8FB@tcb.net> <60D433F0-D9E5-428E-8A79-47EE5E1CECFE@tcb.net> Date: Tue, 29 Nov 2011 11:18:06 -0500 To: Danny McPherson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] Origin Ops, TALs and Local TAs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 16:27:20 -0000 At 10:49 AM -0500 11/29/11, Danny McPherson wrote: >On Nov 29, 2011, at 10:36 AM, Christopher Morrow wrote: > >> I think this last bit gets at danny's concern (after the 'but every >> asn in the path has to agree that the root is wrong' bit)... lots more >> complexity here is not helpful :( > >Yes. > >-danny The characterization above is not quite right, but close :-). The fundamental notion of LTA is that each RP is the "root." That's a good model for PKIs in general, not just the RPKI, as it allows an RP to accept putative roots and impose constraints on them. (This is the opposite of the browser model.) But, as in most of life, TANSTAAFL. The 3779 extensions that help ensure that a misbehaving CA is limited in the extent of the damage it can inflict on the rest of the RPKI also makes it more complex to use the generic LTA model. It is accurate to say then when an RP wants to adopt a different view of the RPKI then there is more work involved. Hierarchies are often adopted because they make it easier to organize and to distribute a workload. So, there is a tradeoff, intrinsically, when an RP wants to pick and choose data from a hierarchy. If a set of ASes want to let some third party do all of this for them, then they could use the LTA mechanisms to do that, in a trivial fashion. But, that approach give up all local control, and so it has its own downside. Steve From internet-drafts@ietf.org Tue Nov 29 09:10:26 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFD321F8A57; Tue, 29 Nov 2011 09:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neCliGf0ixE7; Tue, 29 Nov 2011 09:10:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72A421F85B9; Tue, 29 Nov 2011 09:10:24 -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: 3.64 Message-ID: <20111129171024.13083.74762.idtracker@ietfa.amsl.com> Date: Tue, 29 Nov 2011 09:10:24 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 17:10:27 -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 G= roup of the IETF. Title : Algorithm Agility Procedure for RPKI. Author(s) : Roque Gagliano Stephen Kent Sean Turner Filename : draft-ietf-sidr-algorithm-agility-04.txt Pages : 29 Date : 2011-11-29 This document specifies the process that Certification Authorities (CAs) and Relying Parties (RP) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed in a time scale of months or years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-algorithm-agility-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-algorithm-agility-04.txt From rogaglia@cisco.com Tue Nov 29 09:15:07 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719281F0C72 for ; Tue, 29 Nov 2011 09:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzUCZiG1c9-s for ; Tue, 29 Nov 2011 09:15:06 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 9CADD1F0C76 for ; Tue, 29 Nov 2011 09:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=12732; q=dns/txt; s=iport; t=1322586905; x=1323796505; h=from:subject:date:references:to:message-id:mime-version; bh=oZ07PG7cbLjsyA809feZg14DpRRPmOf556DSXKHRqv8=; b=Y4CQAIZlPthrrxAKbLCNoQpHXXEkRuqlOW0kks0sdxAMYVSeg4eh/G0p VI/iCacX/mXwEAFp77ngnx1dN9A6KkYJh973G3oxUUMVZFHac09dVOs8P xmIQ0rmz8chCUzGuIDOhzagqrVjN++DgjltaC05wR5drG6pQuQN8TRwgb A=; X-Files: smime.p7s : 4389 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAA4S1U6Q/khR/2dsb2JhbABDqnqBBYFyAQEBAwESAWQHCxwDAQIvAksCCAYTIodjmQMBnkyKO2MEjgmGS5IS X-IronPort-AV: E=Sophos;i="4.69,592,1315180800"; d="p7s'?scan'208,217";a="4008878" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 29 Nov 2011 17:15:03 +0000 Received: from ams3-vpn-dhcp6503.cisco.com (ams3-vpn-dhcp6503.cisco.com [10.61.89.102]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pATHF3vX003299 for ; Tue, 29 Nov 2011 17:15:03 GMT From: Roque Gagliano Content-Type: multipart/signed; boundary=Apple-Mail-486-682318500; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 29 Nov 2011 18:14:56 +0100 References: <20111129171026.13083.85070.idtracker@ietfa.amsl.com> To: sidr wg list Message-Id: <54B2A2BE-451F-4EF8-BE9A-11BA454B3712@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 17:15:07 -0000 --Apple-Mail-486-682318500 Content-Type: multipart/alternative; boundary=Apple-Mail-485-682312981 --Apple-Mail-485-682312981 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear WG,=20 We just submitted a new version of the agility draft, where we believe = we addressed all the comments during WGLC. Particularly: - Decoupling the documents to be updated in two, one signaling = the algorithms and another one (BCP) with the specific dates. - Adding a roll-over mechanism for the process. - Several text improvements and editorial nits Regards, Roque Begin forwarded message: > From: internet-drafts@ietf.org > Date: November 29, 2011 6:10:26 PM GMT+01:00 > To: rogaglia@cisco.com > Cc: turners@ieca.com, rogaglia@cisco.com, kent@bbn.com > Subject: New Version Notification for = draft-ietf-sidr-algorithm-agility-04.txt >=20 > A new version of I-D, draft-ietf-sidr-algorithm-agility-04.txt has = been successfully submitted by Roque Gagliano and posted to the IETF = repository. >=20 > Filename: draft-ietf-sidr-algorithm-agility > Revision: 04 > Title: Algorithm Agility Procedure for RPKI. > Creation date: 2011-11-29 > WG ID: sidr > Number of pages: 29 >=20 > Abstract: > This document specifies the process that Certification Authorities > (CAs) and Relying Parties (RP) participating in the Resource Public > Key Infrastructure (RPKI) will need to follow to transition to a new > (and probably cryptographically stronger) algorithm set. The = process > is expected to be completed in a time scale of months or years. > Consequently, no emergency transition is specified. The transition > procedure defined in this document supports only a top-down = migration > (parent migrates before children). >=20 >=20 >=20 >=20 > The IETF Secretariat --Apple-Mail-485-682312981 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii - = Decoupling the documents to be updated in two, one signaling the = algorithms and another one (BCP) with the specific = dates.
= - Adding a roll-over mechanism for the = process.
- Several text improvements and = editorial = nits

Regards,
Roque


Begin forwarded message:

Date: November 29, 2011 6:10:26 PM = GMT+01:00
=
Subject: New Version = Notification for = draft-ietf-sidr-algorithm-agility-04.txt

A = new version of I-D, draft-ietf-sidr-algorithm-agility-04.txt has been = successfully submitted by Roque Gagliano and posted to the IETF = repository.

Filename: = draft-ietf-sidr-algorithm-agility
Revision: = 04
Title: = = Algorithm Agility Procedure for RPKI.
Creation date: = 2011-11-29
WG ID: sidr
Number of pages: = 29

Abstract:
  This document specifies the process = that Certification Authorities
  (CAs) and Relying Parties = (RP) participating in the Resource Public
  Key = Infrastructure (RPKI) will need to follow to transition to a new
=   (and probably cryptographically stronger) algorithm set. =  The process
  is expected to be completed in a time = scale of months or years.
  Consequently, no emergency = transition is specified.  The transition
  procedure = defined in this document supports only a top-down migration
=   (parent migrates before children).




The = IETF Secretariat

= --Apple-Mail-485-682312981-- --Apple-Mail-486-682318500 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEFyqcUyRFrhvN5s0SHw/EO4wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA1MTAwMDAwMDBaFw0x MjA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxIp28SUiJ/fiFYD/Nct8MUbG WJuPqSnhkfBYMFbbWfDDrHR8OXzK2LkWIuHY5aeAo1nalAQCO40oeTYt0cp9W++a7USNCEDQzgVN Rg0YMYL27YSQoVJnecO3u9wi0jjwhJGblWWxphaztdaMbqiChgND1PHqf7dcs4UjeUOhhKFk0/61 mTmduV721jrxj6ABIlUHAc7nXhKANtDbKdBZzEhM4dbzp6STKq65EQ3xRLVFIuapTgNVckvXtc1e Cyu4xLOLZgaD2aLq9JzBn9y/rFRMtf2euP/Nmzl7QRjAUjpPdo1n6NXWGDtNyR0lUrcJ/x1leccZ Gfj0eaqe+tpJmQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAsvqKrlga/tU0vyBtnBOj 4miDAZxou0/fN2wVEK7dRLzIQLYEJD35sELVhiP8v8wVHtgOeVHz9FyBEVqXmJ0RKy4kMC7gdQxj +t1MlqSTDShEaPMmiwaK6M1iJ9jpBL4JvoiirpHnQYGukkgvTUeqITWZ5ecg03nB3QHuab91Gc+n RZ1OKL4D4p5IkvzWhRlIAlxW9yGZyB8r9V6iu3+1SYEpPPUN3AYCxXeXrn8fJjkOoEodybRiGyfW pMpShpTZg2tHB7ZX162Ti3sRvwA2mktDMnBtEm1pXo15z7yieDUPmjVybMA4byV7AQcbIrjQj0eq c/biBsueC2KWoJY7TDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRIfD8Q7jAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEx MjkxNzE1MDJaMCMGCSqGSIb3DQEJBDEWBBTFhvfAM5WLOh7uJu5FWr/KuKsKQDCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQBcDBKEAx2+XalyWlq0AMM8wEIN+XJmZs1koYP8EZHozjTj ezafEqMbfBRNdDlawoXPkuchnjlzy7BgBgXhDVZJ5yXBRNQc2MNClQBx4e0TF/UWrre9ab1f8p+n tIhOxmj+A+cy+Xv5yR5IIbcOpAL9BZN43oKLdYDTsaTHNGBkrCme1AvF7Sh3KZoQVC6vDfIxtleY JmUWK+nqCmcIK0JiutQ4WVZtRnG/X3Z3lTQLeoiAV7IYgwN+TLPmB8BPeVSd+q0ooBheooIvTFnA lx0l2eAvXYRJ7xl8OCndIT5YLxeFvUlarGZab2+4e9oSp0YjI3fGdesYHWxyghInMVIwAAAAAAAA --Apple-Mail-486-682318500-- From iesg-secretary@ietf.org Tue Nov 29 14:51:09 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1841A21F8C09; Tue, 29 Nov 2011 14:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGwxprt1A0-s; Tue, 29 Nov 2011 14:51:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBDCB21F8B63; Tue, 29 Nov 2011 14:51:06 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111129225106.25323.811.idtracker@ietfa.amsl.com> Date: Tue, 29 Nov 2011 14:51:06 -0800 Cc: sidr@ietf.org Subject: [sidr] Last Call: (The RPKI/Router Protocol) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 22:51:09 -0000 The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'The RPKI/Router Protocol' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-12-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In order to formally validate the origin ASs of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Wed Nov 30 05:11:48 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF12C21F8A6C; Wed, 30 Nov 2011 05:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7atjPPsg1VeD; Wed, 30 Nov 2011 05:11:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5913521F8488; Wed, 30 Nov 2011 05:11:47 -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: 3.64 Message-ID: <20111130131147.29082.69643.idtracker@ietfa.amsl.com> Date: Wed, 30 Nov 2011 05:11:47 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-20.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 13:11:48 -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 G= roup of the IETF. Title : The RPKI/Router Protocol Author(s) : Randy Bush Rob Austein Filename : draft-ietf-sidr-rpki-rtr-20.txt Pages : 25 Date : 2011-11-30 In order to formally validate the origin ASs of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-20.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-20.txt From randy@psg.com Wed Nov 30 05:16:42 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B226721F8B21 for ; Wed, 30 Nov 2011 05:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziwOlWAB7oez for ; Wed, 30 Nov 2011 05:16:42 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 847CF21F8AF5 for ; Wed, 30 Nov 2011 05:16:40 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RVk1f-0008vO-W3 for sidr@ietf.org; Wed, 30 Nov 2011 13:16:40 +0000 Date: Wed, 30 Nov 2011 22:17:06 +0900 Message-ID: From: Randy Bush To: sidr wg list References: <20111130131147.29082.39244.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: [sidr] diff of rpki-rte X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 13:16:42 -0000 tools seems not to send the diff to the wg, so here you go randy --- From: internet-drafts@ietf.org To: sidr-chairs@tools.ietf.org, draft-ietf-sidr-rpki-rtr@tools.ietf.org, stbryant@cisco.com Date: Wed, 30 Nov 2011 05:11:47 -0800 Subject: New Version Notification - draft-ietf-sidr-rpki-rtr-20.txt New version (-20) has been submitted for draft-ietf-sidr-rpki-rtr-20.txt. http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-20.txt Diff from previous version: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rpki-rtr-20 IETF Secretariat. From achi@bbn.com Wed Nov 30 07:38:48 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC7A21F8B4F for ; Wed, 30 Nov 2011 07:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_DOSE=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uK6nguJ7dGxB for ; Wed, 30 Nov 2011 07:38:48 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D964321F8B4E for ; Wed, 30 Nov 2011 07:38:47 -0800 (PST) Received: from dhcp89-089-139.bbn.com ([128.89.89.139]:51013 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RVmFD-000JKz-4G for sidr@ietf.org; Wed, 30 Nov 2011 10:38:47 -0500 Message-ID: <4ED64E04.7030408@bbn.com> Date: Wed, 30 Nov 2011 10:38:44 -0500 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: sidr wg Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] RPKI validator testing summary X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 15:38:48 -0000 Several people have expressed a desire to be kept informed about RPKI validator testing, so I'm sending a brief summary to the list. At IETF 82, Rob Austein, Tim Bruijnzeels, and I did some more RPKI validator testing. If there are other validator implementers out there, please let us know so we can include you. Data Sets Good Data: The well-known trust anchors list that Rob assembled http://subvert-rpki.hactrn.net/trunk/rcynic/sample-trust-anchors/ Bad Data: BBN's RPKI Syntax Conformance repository TA: rsync://rpki.bbn.com/conformance/root.cer Previously we compared validators on good data. This time we added specially crafted bad data, where each of 161 input files was intended designed to violate a single item in the spec. The violations range from mundane (negative serial number) to serious (SKI != hash of public key), but we intended each case to be detectable using the standalone file, without referencing other files. Overall Results The "Good Data" testing confirmed that all three validators currently agree, modulo some known minor issues/differences: - rcynic: key usage checking - RIPE: stale CRL strictness - BBN: bottom-up processing, scope of subdir chasing The "Bad Data" testing is a work-in-progress, but the BBN conformance test cases have already proven useful in revealing corner cases in the validators. All three validators (rcynic, RIPE, BBN) will benefit from more robust error handling due to this test set. Sunday's session was also useful for debugging the syntax conformance cases themselves. Credit where it's due: various Cert/CRL AKI issues (thanks Rob), various CMS encoding issues + "good" CMS case for contrast (thanks Tim), missing top-level MFT/CRL (thanks Tim). Another useful side-effect of the testing was that it raised some questions about relying party gray areas. Relying party gray-areas The specs leave room for the relying party to decide what to do with imperfect but not completely invalid objects. This is for good reason. But I believe implementers could benefit from an informational doc or BCP to guide them in these gray areas. Here are two examples we came across: 1. An invalid CRL casts doubt on, and depending on the strictness of the validator, potentially invalidates the manifest in the same directory. This is because the EE cert in the manifest is no longer perfect -- it *could* have been revoked by a CRL. In a sense, this is the strictest interpretation of the spec. But one could also imagine wanting more resilience against an attacker who can remove a CRL. This is left up to the RP right now and the current implementations differ. 2. AIA correctness. Does res-certs require validators to reject a certificate with a messed up AIA URI, even if top-down traversal is ok? Having clean AIAs obviously helps bottom-up validators. But validators capable of bottom-up traversal must already defend against AIA-wild-goose-chase DoS, e.g. by limiting chase depth. Should we encourage validators to enforce AIA correctness? Matt Lepinski and I are currently thinking about how to structure a document that will help RP implementers make informed decisions in these types of cases. -Andrew From randy@psg.com Wed Nov 30 23:00:07 2011 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C011F0C68 for ; Wed, 30 Nov 2011 23:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_DOSE=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7kMmZG-rLOd for ; Wed, 30 Nov 2011 23:00:07 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1992B1F0C67 for ; Wed, 30 Nov 2011 23:00:07 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RW0co-000CSO-8E; Thu, 01 Dec 2011 07:00:06 +0000 Date: Thu, 01 Dec 2011 16:00:32 +0900 Message-ID: From: Randy Bush To: Andrew Chi In-Reply-To: <4ED64E04.7030408@bbn.com> References: <4ED64E04.7030408@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg Subject: Re: [sidr] RPKI validator testing summary X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 07:00:07 -0000 > 2. AIA correctness. Does res-certs require validators to reject a > certificate with a messed up AIA URI, even if top-down traversal is ok? > Having clean AIAs obviously helps bottom-up validators. But > validators capable of bottom-up traversal must already defend against > AIA-wild-goose-chase DoS, e.g. by limiting chase depth. Should we > encourage validators to enforce AIA correctness? as i hope i made clear in taipei, i can see no reason to tolerate useless incorrectness randy, proud to be a naggumite