From sidr-bounces@ietf.org Sat Mar 1 10:50:20 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F69428C246; Sat, 1 Mar 2008 10:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7e1hXusRkFC; Sat, 1 Mar 2008 10:50:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 231E63A6AF9; Sat, 1 Mar 2008 10:50:19 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FCD93A69AC for ; Sat, 1 Mar 2008 10:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lk8tpgBXTG8r for ; Sat, 1 Mar 2008 10:50:12 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 6B4F928C1B7 for ; Sat, 1 Mar 2008 10:50:12 -0800 (PST) Received: from dhcp89-089-119.bbn.com ([128.89.89.119] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JVWmT-0001HV-63; Sat, 01 Mar 2008 13:49:57 -0500 Message-ID: <47C9A49F.6030404@bbn.com> Date: Sat, 01 Mar 2008 13:46:55 -0500 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Austein References: <478F6BFA.8090301@bbn.com> <20080229234246.502D222808@thrintun.hactrn.net> In-Reply-To: <20080229234246.502D222808@thrintun.hactrn.net> Cc: sidr@ietf.org Subject: Re: [Sidr] Multiple Signatures on a ROA: Proposal X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Rob, Thanks for your feedback. I understand your skeptism about the need for multiple signatures. Ultimately, no one can see the future well enough to know how often such a mechanism will be needed. However, if the mechanism is needed and we don't support it, it's not the kind of thing that can be added later in any reasonable manner. With regards to your comments, I'm happy to clearly specify that (1) All signatures must be valid or the ROA; and (2) Two signatures covering overlapping IP address ranges are not allowed. With regards to the ExactMatch flag, the intent of the ExactMatch flag is to specify the rules for matching the prefix(es) in a ROA with the prefix(es) advertised in a BGP UPDATE. That is, when ExactMatch is TRUE the AS must advertise exactly the prefix(es) listed in the ROA, where as if ExactMatch is FALSE then the AS may advertise more specific (longer) prefixes than those listed in the ROA. In either case, I belive the addresses in the ROA should exactly match the (union) of the addresses in the EE certificate(s) regardless of whether there is one or more signature on the ROA. Personally, I would like to see the specification dictate that any SignerInfo whose digest algorithm is not SHA-256 be ignored (treated as if it were not present) by the validation algorithm. I do not believe this adds much additional complexity and I believe that if we do not such a provision, then we will be stuck with SHA-256 forever (and if we do add such a provision then at some point in the distant future the spec could be updated to allow backwards-compatible migration to a new digest algorithm). That point aside for the moment, based on your comments I would propose to re-write the ROA validation algorithm as follows. [Please let me know if you have any suggestions for improving this text, especially if you see a way to make the description simpler/clearer] 1. Verify that the ROA syntax complies with the syntax specified in draft-ietf-sidr-roa-format. If the syntax is improper in any way, then the ROA is invalid. 2. Process each SignerInfo object in the SignerInfos list, as follows: 2.1 Obtain an EE certificate whose Subject Key Identifier (SKI) matches the sid field of the SignerInfo object. This certificate may be obtained from the certificates field of the SignedData object (if present), the resource PKI repository system, or a local cache. 2.2 Use the public key in the EE certificate to verify the signature on the ROA. If the signature is invalid then the ROA is invalid. 2.3 Verify that the EE certificate is a valid end-entity certificate in the resource PKI by constructing a valid certificate path to a trust anchor. (See draft-ietf-sidr-res-certs for more details.) If the EE certificate is invalid then the ROA is invalid. 2.4 Verify that the EE certificate has an IP Address Delegation extension [RFC3779]. If the IP address range specificed in the RFC 3779 extension overlaps with any IP address range corresponding to a previous SignerInfo Object, then the ROA is invalid. 3. Compute the union of IP address ranges in the RFC 3779 extensions of the EE certificates used to verify the signatures in Step 2. If this union exactly matches the IP address prefix(es) in the ROA, then the ROA is valid, otherwise it is invalid. Note: Again, I would propose adding a Step 2.0 that says "If the digestAlgorithm of the SignerInfo object is not SHA-256, then ignore the SignerInfo object and proceed to the next SignerInfo object." - Matt Lepinski :-> Rob Austein wrote: >I remain quite skeptical about the need for this, but will suspend >disbelief on that point for the remainder of this message. > >The proposal is too complicated for the stated purpose, mostly because >it allows overlapping resource sets. That drags in all sorts of fun >topics, such as partial overlaps, overlaps with multiple algorithms, >downgrade attacks, deciding how many good signatures is enough, >etcetera ad nauseum. > >Complicated decision trees means multiple code paths. Rarely used >code paths will be buggy. Buggy code paths will be an attack vector. >This is supposed to be security software. Keep it simple. > >If you must support multiple signatures, do it as simply as possible: > >- All signatures must be good, if any are bad, so is the ROA. Full > stop. > >- Overlaps are not allowed, full stop. > >- If the ROA's exactMatch field is true, the prefixes listed in the > ROA must be an exact match for the union of the set of prefixes > covered by the certs; otherwise, the prefixes listed in the ROA must > be a subset (possibly improper) of the union of the resources in the > cert. >_______________________________________________ >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 sidr-bounces@ietf.org Sun Mar 2 08:40:45 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9183A68BB; Sun, 2 Mar 2008 08:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.59 X-Spam-Level: X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SonhE+RLzqx; Sun, 2 Mar 2008 08:40:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32123A69B3; Sun, 2 Mar 2008 08:40:33 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69A1B3A6A6D for ; Sun, 2 Mar 2008 08:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLhszQqGA+9C for ; Sun, 2 Mar 2008 08:40:28 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id C52B23A6D81 for ; Sun, 2 Mar 2008 08:37:49 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 25so5983905wfa.31 for ; Sun, 02 Mar 2008 08:37:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=XyfwY+Thq8ZXAL6cFFyY772AVKh+sGTX2d3YYUBLUoA=; b=Oh+5MXjp5zWR5kw1Y7O77O2MG+2occOyw/oEQP3AWPjEPBV2dtnRJ3IxeCL2tCxix7luBJbVnt/yctiD0y8A/On4mwYa0AsPkUy3G634vPsmsASP6QOsQzyQlTCyir/m2hF42sjrT08I1eFeJaKVgf7WQKcilcwsLuEmzy3JtfA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AQwNCxinfIWAU0GPpTXCq96nSLGA3WWhvEsdgvz5l4hi8rgwzgWuVlaJNrsdgJNKUscsv20oPcSqRJ5GfN73xPilzyfmVUXfKJ1SQ+NFJNI9sBI1omuoc5J5SkvAMH7s0iCmKF96HeOU7ANzCoqxmixcZO/AVXEpdBqSGW2Q/GM= Received: by 10.142.89.9 with SMTP id m9mr8404181wfb.116.1204475861520; Sun, 02 Mar 2008 08:37:41 -0800 (PST) Received: by 10.143.164.14 with HTTP; Sun, 2 Mar 2008 08:37:41 -0800 (PST) Message-ID: <77ead0ec0803020837s16bccee8ledbc9ae1bb60e117@mail.gmail.com> Date: Sun, 2 Mar 2008 08:37:41 -0800 From: "Vishwas Manral" To: "Sandra Murphy" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <47C4E38E.1070105@bogus.com> <77ead0ec0802272031j6d958279tf3028c4096093020@mail.gmail.com> <77ead0ec0802280649k66671fc9s9fc24314963c68a0@mail.gmail.com> <77ead0ec0802280956s3dcff81cx25fd152ea1c798fb@mail.gmail.com> <77ead0ec0802281056y2862d71dt8b753f5f3f3b0df9@mail.gmail.com> <77ead0ec0802281102o3e2efedl479ff6351dca0f63@mail.gmail.com> Cc: Roland Dobbins , opsec wg mailing list , sidr@ietf.org Subject: Re: [Sidr] [OPSEC] pccw as17557 leak... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi Sandra, I also noted the services of RIPE are currently accessible through http and not https. That is an issue too. I have notified RIPE about the same. Thanks, Vishwas On Thu, Feb 28, 2008 at 1:12 PM, Sandra Murphy wrote: > > > On Thu, 28 Feb 2008, Vishwas Manral wrote: > > > Hi Sandra, > > > > > To further clarify, > >> The only point I want to add to the discussion is because we have to > >> verify the Origin only in the first hop peer, we do not need a global > >> database (as I mentioned we are not saving against malicious attacks > >> in any case). > > This would mean for someone who gets the information from RIPE does > > not need to necessarily use the mechanism the way it currently stands. > > > > > As long as: > > (a) you were interested in protecting only those prefixes that are managed > by RIPE - data in RIPE about other prefixes doesn't fall under the > protection of their security model, and the RIPE database does not > contain all prefixes, > > and > > (b) you were comfortable with the trust model of RIPE (they authenticate > the upload of the data with varying strength of authentication and you > must get the data, whose aussurance you can not yourself verify, from them > and only them with a protected transport they support). > > As an additional wrinkle, I believe that RIPE does allocate prefixes to > LIRs. I do not know if the LIRs are required to maintain the RIPE > security model in their allocations. > > --Sandy > _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 4 07:05:08 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA0DA28C352; Tue, 4 Mar 2008 07:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QD16KvFt3Ba7; Tue, 4 Mar 2008 07:05:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DEA328C122; Tue, 4 Mar 2008 07:05:02 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC0773A6B13; Tue, 4 Mar 2008 07:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7arVd+tQJKfh; Tue, 4 Mar 2008 07:04:57 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [199.212.90.4]) by core3.amsl.com (Postfix) with ESMTP id 02F0F3A6ABA; Tue, 4 Mar 2008 07:04:56 -0800 (PST) Received: from [199.212.90.17] (helo=yxu1a17.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWYhA-000Abi-4R; Tue, 04 Mar 2008 15:04:44 +0000 Message-Id: <7C9DBE28-7B7A-4053-85AE-4B954FFEEC57@ca.afilias.info> From: Joe Abley To: Vishwas Manral In-Reply-To: <77ead0ec0803020837s16bccee8ledbc9ae1bb60e117@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 4 Mar 2008 10:04:43 -0500 References: <47C4E38E.1070105@bogus.com> <77ead0ec0802272031j6d958279tf3028c4096093020@mail.gmail.com> <77ead0ec0802280649k66671fc9s9fc24314963c68a0@mail.gmail.com> <77ead0ec0802280956s3dcff81cx25fd152ea1c798fb@mail.gmail.com> <77ead0ec0802281056y2862d71dt8b753f5f3f3b0df9@mail.gmail.com> <77ead0ec0802281102o3e2efedl479ff6351dca0f63@mail.gmail.com> <77ead0ec0803020837s16bccee8ledbc9ae1bb60e117@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) Cc: opsec wg mailing list , sidr@ietf.org Subject: Re: [Sidr] [OPSEC] pccw as17557 leak... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 2-Mar-2008, at 11:37, Vishwas Manral wrote: > I also noted the services of RIPE are currently accessible through > http and not https. That is an issue too. An issue for what or whom? And what do you mean by "the services"? Joe _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 4 07:14:50 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE35528C484; Tue, 4 Mar 2008 07:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.695 X-Spam-Level: X-Spam-Status: No, score=-0.695 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzxZaVIIFLnx; Tue, 4 Mar 2008 07:14:45 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7402E3A68DF; Tue, 4 Mar 2008 07:14:45 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 761143A6BFC for ; Tue, 4 Mar 2008 07:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UWEDM5At4vT for ; Tue, 4 Mar 2008 07:14:37 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.187]) by core3.amsl.com (Postfix) with ESMTP id 3E5A128C5DC for ; Tue, 4 Mar 2008 07:14:25 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id i36so715859gve.15 for ; Tue, 04 Mar 2008 07:14:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=k/yYZKStv3qTTZ6BX/QhYNcSo2p2G+woeg0+cAooibo=; b=nDkNoATIG9cXM2OT+F4cMcv3pWt6Hegw9aKPSFOQ4qp8srX9owNNzlaLDn77py2jQXFxKUP/qk5jFMc6S3zyyxUIJcOJvqoe9AFIDyHS7epshCFzxU6HaNOzXvmAKLljcPDegjiW1LJ2dv0Hb6D2Crv3WglqgWBKHosHvGe1GA4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QM5IPWstXMaKV2wCwpLVHTpqf4troZbFZvU/LUvi5+PVyfovfhB1izTCFtwZXF1rThi5N4Ur985HCjEnv4G/EA05bRk+6oqsEPst45yQTk8TcR/W1ercbtI+572JtzMRL+Y+HcOI2t3Bhi22BkhDB05P2szrKR6W7rflLPmlKiI= Received: by 10.142.52.9 with SMTP id z9mr528293wfz.237.1204643654013; Tue, 04 Mar 2008 07:14:14 -0800 (PST) Received: by 10.143.164.14 with HTTP; Tue, 4 Mar 2008 07:14:13 -0800 (PST) Message-ID: <77ead0ec0803040714v4235cff2u65bd247694e30570@mail.gmail.com> Date: Tue, 4 Mar 2008 07:14:13 -0800 From: "Vishwas Manral" To: "Joe Abley" In-Reply-To: <7C9DBE28-7B7A-4053-85AE-4B954FFEEC57@ca.afilias.info> MIME-Version: 1.0 Content-Disposition: inline References: <47C4E38E.1070105@bogus.com> <77ead0ec0802280649k66671fc9s9fc24314963c68a0@mail.gmail.com> <77ead0ec0802280956s3dcff81cx25fd152ea1c798fb@mail.gmail.com> <77ead0ec0802281056y2862d71dt8b753f5f3f3b0df9@mail.gmail.com> <77ead0ec0802281102o3e2efedl479ff6351dca0f63@mail.gmail.com> <77ead0ec0803020837s16bccee8ledbc9ae1bb60e117@mail.gmail.com> <7C9DBE28-7B7A-4053-85AE-4B954FFEEC57@ca.afilias.info> Cc: opsec wg mailing list , sidr@ietf.org Subject: Re: [Sidr] [OPSEC] pccw as17557 leak... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi Joe, I was talking about the RIPE whois and other related tools that RIPE provides, when I looked at the link given below: http://www.ripe.net/news/study-youtube-hijacking.html As the tools cannot be accessed using https but using http, the tools cannot be used in a guaranteed fashion. We cannot build scripts over the tools and feel the information. Thanks, Vishwas On Tue, Mar 4, 2008 at 7:04 AM, Joe Abley wrote: > > On 2-Mar-2008, at 11:37, Vishwas Manral wrote: > > > I also noted the services of RIPE are currently accessible through > > http and not https. That is an issue too. > > An issue for what or whom? And what do you mean by "the services"? > > > Joe > > _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 4 07:25:38 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C046C28C458; Tue, 4 Mar 2008 07:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.833 X-Spam-Level: X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72Ea1IQAtLRk; Tue, 4 Mar 2008 07:25:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83AC53A6D79; Tue, 4 Mar 2008 07:25:24 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FCAB28C202; Tue, 4 Mar 2008 07:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FqjPofLolkx; Tue, 4 Mar 2008 07:25:17 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [199.212.90.4]) by core3.amsl.com (Postfix) with ESMTP id 9FB7628C57C; Tue, 4 Mar 2008 07:22:55 -0800 (PST) Received: from [199.212.90.17] (helo=yxu1a17.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWYyX-000AhO-8M; Tue, 04 Mar 2008 15:22:43 +0000 Message-Id: <5B7F4259-8CAB-4895-8F26-8BFD0CE7C56B@ca.afilias.info> From: Joe Abley To: Vishwas Manral In-Reply-To: <77ead0ec0803040714v4235cff2u65bd247694e30570@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 4 Mar 2008 10:22:39 -0500 References: <47C4E38E.1070105@bogus.com> <77ead0ec0802280649k66671fc9s9fc24314963c68a0@mail.gmail.com> <77ead0ec0802280956s3dcff81cx25fd152ea1c798fb@mail.gmail.com> <77ead0ec0802281056y2862d71dt8b753f5f3f3b0df9@mail.gmail.com> <77ead0ec0802281102o3e2efedl479ff6351dca0f63@mail.gmail.com> <77ead0ec0803020837s16bccee8ledbc9ae1bb60e117@mail.gmail.com> <7C9DBE28-7B7A-4053-85AE-4B954FFEEC57@ca.afilias.info> <77ead0ec0803040714v4235cff2u65bd247694e30570@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) Cc: opsec wg mailing list , sidr@ietf.org Subject: Re: [Sidr] [OPSEC] pccw as17557 leak... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 4-Mar-2008, at 10:14, Vishwas Manral wrote: > I was talking about the RIPE whois and other related tools that RIPE > provides, when I looked at the link given below: > http://www.ripe.net/news/study-youtube-hijacking.html > > As the tools cannot be accessed using https but using http, the tools > cannot be used in a guaranteed fashion. We cannot build scripts over > the tools and feel the information. I had no idea they were available over http. Everybody I know who uses them uses whois. As to "cannot build", that doesn't seem to be an opinion shared by the many ISPs who "have built". Joe _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 4 07:29:49 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1F7F28C116; Tue, 4 Mar 2008 07:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.59 X-Spam-Level: X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuthrnWmrC4G; Tue, 4 Mar 2008 07:29:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 620A428C458; Tue, 4 Mar 2008 07:29:36 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0951828C23D for ; Tue, 4 Mar 2008 07:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNGQd96IU1a2 for ; Tue, 4 Mar 2008 07:29:34 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id A46C228C57C for ; Tue, 4 Mar 2008 07:28:01 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 25so1121274wfa.31 for ; Tue, 04 Mar 2008 07:27:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=EP6rZzrEy0mdKBlsIMgUakBhEe6oalsdc3+e8+fKKWk=; b=LYZrTmTX92NLLdtuLACtV+CXBYAECJGBlgzNXOlwYrDoM08fFGy2PMnIbw3modFkRAMPMcWnweMvSBgLqGpBRj/NOShHqNohowoKhRrRGoclLrAGk8orxyZZcq0xceuvPN7WuittIdj/c8i+WgtLz/0TK+Mwf1M/RqDlWqRLlL0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=R1EO14JrdNBMc/xrZ37tpacyRlGItQwGEG4w6RGw/qdFBX+ZJYYkoxE/wJGbDlNoxKaPmXHsOveztR5kTzffIIEUdGA6SqtWODHZiidPT7br28vnBbxoKlc4dAGFBcNEH+vnuF31VuiHVyM32Iwy/hvpXwTtW3DtS5cOKAHUlt4= Received: by 10.143.37.20 with SMTP id p20mr528315wfj.236.1204644472445; Tue, 04 Mar 2008 07:27:52 -0800 (PST) Received: by 10.143.164.14 with HTTP; Tue, 4 Mar 2008 07:27:52 -0800 (PST) Message-ID: <77ead0ec0803040727n24b68e0fm5650e8fb6c1b1dc@mail.gmail.com> Date: Tue, 4 Mar 2008 07:27:52 -0800 From: "Vishwas Manral" To: "Joe Abley" In-Reply-To: <5B7F4259-8CAB-4895-8F26-8BFD0CE7C56B@ca.afilias.info> MIME-Version: 1.0 Content-Disposition: inline References: <47C4E38E.1070105@bogus.com> <77ead0ec0802280956s3dcff81cx25fd152ea1c798fb@mail.gmail.com> <77ead0ec0802281056y2862d71dt8b753f5f3f3b0df9@mail.gmail.com> <77ead0ec0802281102o3e2efedl479ff6351dca0f63@mail.gmail.com> <77ead0ec0803020837s16bccee8ledbc9ae1bb60e117@mail.gmail.com> <7C9DBE28-7B7A-4053-85AE-4B954FFEEC57@ca.afilias.info> <77ead0ec0803040714v4235cff2u65bd247694e30570@mail.gmail.com> <5B7F4259-8CAB-4895-8F26-8BFD0CE7C56B@ca.afilias.info> Cc: opsec wg mailing list , sidr@ietf.org Subject: Re: [Sidr] [OPSEC] pccw as17557 leak... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi Joe, > I had no idea they were available over http. Everybody I know who uses > them uses whois. > > As to "cannot build", that doesn't seem to be an opinion shared by the > many ISPs who "have built". The point I raise is about a guarantee of talking to the right server. If the tools are already built and are not checking the certificate of the site they are getting the information from, then that is another weakness in the system, that is breakable. Thanks, Vishwas On Tue, Mar 4, 2008 at 7:22 AM, Joe Abley wrote: > > On 4-Mar-2008, at 10:14, Vishwas Manral wrote: > > > I was talking about the RIPE whois and other related tools that RIPE > > provides, when I looked at the link given below: > > http://www.ripe.net/news/study-youtube-hijacking.html > > > > As the tools cannot be accessed using https but using http, the tools > > cannot be used in a guaranteed fashion. We cannot build scripts over > > the tools and feel the information. > > I had no idea they were available over http. Everybody I know who uses > them uses whois. > > As to "cannot build", that doesn't seem to be an opinion shared by the > many ISPs who "have built". > > > Joe > _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 4 07:37:09 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0E9D3A6D79; Tue, 4 Mar 2008 07:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpNTxMmi78x1; Tue, 4 Mar 2008 07:37:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 229CA28C5EF; Tue, 4 Mar 2008 07:37:02 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4840C28C5EF for ; Tue, 4 Mar 2008 07:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Fenr-XnBFRI for ; Tue, 4 Mar 2008 07:36:55 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 27CB428C0F7 for ; Tue, 4 Mar 2008 07:36:51 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 25so1128011wfa.31 for ; Tue, 04 Mar 2008 07:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=04mFTwuhMDACRBKjOPwpHNZr9fc0lRqs0W/8dBf2r7I=; b=bLA1mXbhbkP/tniX1DzeQWDHNHSp0Z7ud6E+1Xs47RFabf2IXkqXQP8X3UvLARCNZIb2pYfYCMAMnMQst6BZEoy1XSQQtQEVpWmkS3cGbkQ+MKN4sVEz3h9kX6aBS8Vp/yxFTFMH0it/YHjkpB9fH3jtCb+8MW9dOMnY7eqdCh0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nvpEcCqCzlt4RPpsg6J96/bAp3mGOaiSldWGfwVG6g7gcA/IB48lhqOTkFiVvPNUspPWq15BtjnTwwNDsLiVfQaFfIeYNAeLK2fBHn0BFwY9KF7BX1UXLtnhx31Hw3c+hcC8tcYLGgzakONzM9AqMecJaAI4s276IGJzRoIsosQ= Received: by 10.143.187.2 with SMTP id o2mr544507wfp.162.1204645001899; Tue, 04 Mar 2008 07:36:41 -0800 (PST) Received: by 10.143.164.14 with HTTP; Tue, 4 Mar 2008 07:36:41 -0800 (PST) Message-ID: <77ead0ec0803040736t55871ebex445e6fe31d6ac129@mail.gmail.com> Date: Tue, 4 Mar 2008 07:36:41 -0800 From: "Vishwas Manral" To: "Joe Abley" In-Reply-To: <77ead0ec0803040727n24b68e0fm5650e8fb6c1b1dc@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <47C4E38E.1070105@bogus.com> <77ead0ec0802281056y2862d71dt8b753f5f3f3b0df9@mail.gmail.com> <77ead0ec0802281102o3e2efedl479ff6351dca0f63@mail.gmail.com> <77ead0ec0803020837s16bccee8ledbc9ae1bb60e117@mail.gmail.com> <7C9DBE28-7B7A-4053-85AE-4B954FFEEC57@ca.afilias.info> <77ead0ec0803040714v4235cff2u65bd247694e30570@mail.gmail.com> <5B7F4259-8CAB-4895-8F26-8BFD0CE7C56B@ca.afilias.info> <77ead0ec0803040727n24b68e0fm5650e8fb6c1b1dc@mail.gmail.com> Cc: opsec wg mailing list , sidr@ietf.org Subject: Re: [Sidr] [OPSEC] pccw as17557 leak... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi Joe, To further explain it. In my view SSL is the right protocol for this kind of transaction (we could use IPSec with BTNS too though). As the idea is to get the information from the right server, the client itself could be any one. Thanks, Vishwas On Tue, Mar 4, 2008 at 7:27 AM, Vishwas Manral wrote: > Hi Joe, > > > > I had no idea they were available over http. Everybody I know who uses > > them uses whois. > > > > As to "cannot build", that doesn't seem to be an opinion shared by the > > many ISPs who "have built". > The point I raise is about a guarantee of talking to the right server. > If the tools are already built and are not checking the certificate of > the site they are getting the information from, then that is another > weakness in the system, that is breakable. > > Thanks, > Vishwas > > > > On Tue, Mar 4, 2008 at 7:22 AM, Joe Abley wrote: > > > > On 4-Mar-2008, at 10:14, Vishwas Manral wrote: > > > > > I was talking about the RIPE whois and other related tools that RIPE > > > provides, when I looked at the link given below: > > > http://www.ripe.net/news/study-youtube-hijacking.html > > > > > > As the tools cannot be accessed using https but using http, the tools > > > cannot be used in a guaranteed fashion. We cannot build scripts over > > > the tools and feel the information. > > > > I had no idea they were available over http. Everybody I know who uses > > them uses whois. > > > > As to "cannot build", that doesn't seem to be an opinion shared by the > > many ISPs who "have built". > > > > > > Joe > > > _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 4 07:43:48 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09F928C536; Tue, 4 Mar 2008 07:43:48 -0800 (PST) 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.369, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fReXdDE+tWC; Tue, 4 Mar 2008 07:43:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008B528C481; Tue, 4 Mar 2008 07:43:40 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48FBE28C116; Tue, 4 Mar 2008 07:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+xFREIN-mHx; Tue, 4 Mar 2008 07:43:34 -0800 (PST) Received: from monster.hopcount.ca (monster.hopcount.ca [199.212.90.4]) by core3.amsl.com (Postfix) with ESMTP id CFDEA3A6D2E; Tue, 4 Mar 2008 07:43:33 -0800 (PST) Received: from [199.212.90.17] (helo=yxu1a17.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JWZIY-000B37-Tu; Tue, 04 Mar 2008 15:43:23 +0000 Message-Id: <6AAD8CE4-1A16-4C8D-A883-EC5D4D80D2FD@ca.afilias.info> From: Joe Abley To: "Vishwas Manral" In-Reply-To: <77ead0ec0803040736t55871ebex445e6fe31d6ac129@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 4 Mar 2008 10:43:21 -0500 References: <47C4E38E.1070105@bogus.com> <77ead0ec0802281056y2862d71dt8b753f5f3f3b0df9@mail.gmail.com> <77ead0ec0802281102o3e2efedl479ff6351dca0f63@mail.gmail.com> <77ead0ec0803020837s16bccee8ledbc9ae1bb60e117@mail.gmail.com> <7C9DBE28-7B7A-4053-85AE-4B954FFEEC57@ca.afilias.info> <77ead0ec0803040714v4235cff2u65bd247694e30570@mail.gmail.com> <5B7F4259-8CAB-4895-8F26-8BFD0CE7C56B@ca.afilias.info> <77ead0ec0803040727n24b68e0fm5650e8fb6c1b1dc@mail.gmail.com> <77ead0ec0803040736t55871ebex445e6fe31d6ac129@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) Cc: opsec wg mailing list , sidr@ietf.org Subject: Re: [Sidr] [OPSEC] pccw as17557 leak... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 4-Mar-2008, at 10:36, Vishwas Manral wrote: > To further explain it. In my view SSL is the right protocol for this > kind of transaction (we could use IPSec with BTNS too though). As the > idea is to get the information from the right server, the client > itself could be any one. That seems like a feasible band-aid over the deficiencies of the existing service, although it's clearly no panacea. It also has the practical problem that existing scripts that use whois would need modification, although the whois "protocol" and client are so trivial that it would presumably be straightforward for someone to implement a change to the (say) BSD client to implement an SSL wrapper with server- side certificate verification. Allowing the integrity of the data itself to be trusted (e.g. using the resource certification work) seems like a more appropriate direction than worrying about the security of data retrieval, though, which perhaps explains why SSL-wrapping whois has not already been done by anybody. Joe _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 4 08:01:53 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA17628C699; Tue, 4 Mar 2008 08:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.666 X-Spam-Level: X-Spam-Status: No, score=-0.666 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1gi4ccpjvCB; Tue, 4 Mar 2008 08:01:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FEE128C5AF; Tue, 4 Mar 2008 08:00:39 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F1913A6A80 for ; Tue, 4 Mar 2008 08:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YT2aqvaEKEN for ; Tue, 4 Mar 2008 08:00:32 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.188]) by core3.amsl.com (Postfix) with ESMTP id D3A4328C650 for ; Tue, 4 Mar 2008 07:59:50 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id i36so740773gve.15 for ; Tue, 04 Mar 2008 07:59:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=CmQsPS+7OVCXoNo+J60mpvILcChLxXb+NhnMeHI2lvk=; b=jcJfV5qLYSAxUxNQcbdDYz18jN51Xze08qMi/8gxwlYHRbCSpaKYQRrHv0XiMhOg4rr5MxMSuHBLBUWzSB4in93oh0SRTRXs6kFHQJHZeud23WbVwDkPZLlYZJD0/xYdgqGyDYdq8/N00MmYwHCd/DZbAhZn9XITQ5ojWQs1BKM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=E9pdqV2PF5xqwmb1B5BSyZKIBXv3B40ESj8lSWe1WnPbDbpvg55gD4VQbZAOvie5CrdCZ0/R0Yf7rZnUHNopl1tLzqtmitVvj14e5GxhEQmkz3DLffhO8q/5cTLvu4YNaVnmRUIrkpuwLdpV2+l4VXgAnJxG7Ua5MtqdpEuSHmE= Received: by 10.142.156.2 with SMTP id d2mr539564wfe.219.1204646379295; Tue, 04 Mar 2008 07:59:39 -0800 (PST) Received: by 10.143.164.14 with HTTP; Tue, 4 Mar 2008 07:59:39 -0800 (PST) Message-ID: <77ead0ec0803040759p4fad1726m9e175625a13d04a6@mail.gmail.com> Date: Tue, 4 Mar 2008 07:59:39 -0800 From: "Vishwas Manral" To: "Joe Abley" In-Reply-To: <6AAD8CE4-1A16-4C8D-A883-EC5D4D80D2FD@ca.afilias.info> MIME-Version: 1.0 Content-Disposition: inline References: <47C4E38E.1070105@bogus.com> <77ead0ec0802281102o3e2efedl479ff6351dca0f63@mail.gmail.com> <77ead0ec0803020837s16bccee8ledbc9ae1bb60e117@mail.gmail.com> <7C9DBE28-7B7A-4053-85AE-4B954FFEEC57@ca.afilias.info> <77ead0ec0803040714v4235cff2u65bd247694e30570@mail.gmail.com> <5B7F4259-8CAB-4895-8F26-8BFD0CE7C56B@ca.afilias.info> <77ead0ec0803040727n24b68e0fm5650e8fb6c1b1dc@mail.gmail.com> <77ead0ec0803040736t55871ebex445e6fe31d6ac129@mail.gmail.com> <6AAD8CE4-1A16-4C8D-A883-EC5D4D80D2FD@ca.afilias.info> Cc: opsec wg mailing list , sidr@ietf.org Subject: Re: [Sidr] [OPSEC] pccw as17557 leak... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi Joe, If you saw the mail exchange between Sandra and I, you will notice she mentioned the reason they have to go ahead with SIDR even though we have tools available from RIPE. What I have been trying to do is to figure out weaknesses. in the current infrastructure to get a secure behavior. As a first step I found out this weakness and updated RIPE/ Daniel about the same. As we discussed earlier SIDR does not provide a totally secure infrastructure. The point here is that SIDR is giving some very basic improvements in the security, generally in the non-malicious case. The idea is can we get a similar security with the current infrastructure, by doing minor improvements. There is a certain cost involved with the SIDR infrastructure. I do not think the SSL channel has not been done because it is unnecessary. I guess there hasn't been an attack on that side of the infrastructure yet, but these are well known issues/ attacks in other fields. Thanks, Vishwas On Tue, Mar 4, 2008 at 7:43 AM, Joe Abley wrote: > > On 4-Mar-2008, at 10:36, Vishwas Manral wrote: > > > To further explain it. In my view SSL is the right protocol for this > > kind of transaction (we could use IPSec with BTNS too though). As the > > idea is to get the information from the right server, the client > > itself could be any one. > > That seems like a feasible band-aid over the deficiencies of the > existing service, although it's clearly no panacea. It also has the > practical problem that existing scripts that use whois would need > modification, although the whois "protocol" and client are so trivial > that it would presumably be straightforward for someone to implement a > change to the (say) BSD client to implement an SSL wrapper with server- > side certificate verification. > > Allowing the integrity of the data itself to be trusted (e.g. using > the resource certification work) seems like a more appropriate > direction than worrying about the security of data retrieval, though, > which perhaps explains why SSL-wrapping whois has not already been > done by anybody. > > > Joe > > _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 4 08:36:41 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBEE828C62F; Tue, 4 Mar 2008 08:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.636 X-Spam-Level: X-Spam-Status: No, score=-0.636 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gviiZSpmkyw2; Tue, 4 Mar 2008 08:36:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE74F28C481; Tue, 4 Mar 2008 08:35:43 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62AEF28C6F5; Tue, 4 Mar 2008 08:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCRMZmcwWFjy; Tue, 4 Mar 2008 08:35:36 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id CE26A28C6F4; Tue, 4 Mar 2008 08:34:38 -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 m24GYJdG026841; Tue, 4 Mar 2008 10:34:19 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m24GYJd8029474; Tue, 4 Mar 2008 10:34:19 -0600 Received: from localhost ([157.185.81.106]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Mar 2008 11:34:19 -0500 Date: Tue, 4 Mar 2008 11:34:18 -0500 (Eastern Standard Time) From: Sandra Murphy To: Vishwas Manral In-Reply-To: <77ead0ec0803040759p4fad1726m9e175625a13d04a6@mail.gmail.com> Message-ID: References: <47C4E38E.1070105@bogus.com> <77ead0ec0802281102o3e2efedl479ff6351dca0f63@mail.gmail.com> <77ead0ec0803020837s16bccee8ledbc9ae1bb60e117@mail.gmail.com> <7C9DBE28-7B7A-4053-85AE-4B954FFEEC57@ca.afilias.info> <77ead0ec0803040714v4235cff2u65bd247694e30570@mail.gmail.com> <5B7F4259-8CAB-4895-8F26-8BFD0CE7C56B@ca.afilias.info> <77ead0ec0803040727n24b68e0fm5650e8fb6c1b1dc@mail.gmail.com> <77ead0ec0803040736t55871ebex445e6fe31d6ac129@mail.gmail.com> <6AAD8CE4-1A16-4C8D-A883-EC5D4D80D2FD@ca.afilias.info> <77ead0ec0803040759p4fad1726m9e175625a13d04a6@mail.gmail.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 04 Mar 2008 16:34:19.0190 (UTC) FILETIME=[9822F560:01C87E15] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Tue, 04 Mar 2008 10:34:19 -0600 (CST) Cc: opsec wg mailing list , sidr@ietf.org Subject: Re: [Sidr] [OPSEC] pccw as17557 leak... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, 4 Mar 2008, Vishwas Manral wrote: > Hi Joe, > > If you saw the mail exchange between Sandra and I, you will notice she > mentioned the reason they have to go ahead with SIDR even though we > have tools available from RIPE. What I have been trying to do is to > figure out weaknesses. in the current infrastructure to get a secure > behavior. As a first step I found out this weakness and updated RIPE/ > Daniel about the same. Please keep in mind that RIPE is not the only IRR. And RIPE can not verify authorization for prefixes and ASs outside its range. So improving RIPE does not buy you what you want. > > As we discussed earlier SIDR does not provide a totally secure > infrastructure. The point here is that SIDR is giving some very basic > improvements in the security, generally in the non-malicious case. Please keep in mind that I have said SIDR does most definitely protect against malicious attacks for those attacks it is addressing. SIDR makes no difference between maliciousness or carelessness in the attacks it counters. There are plenty of malicious and accidental ways to attack routers that are not in the realm of what SIDR is considering now. Maliciousness is not the distinguisher here. To be plain, to say SIDR addresses only non-malicious cases is flat out WRONG. (And sorry for not having pointed that out before, I thought I did.) > The > idea is can we get a similar security with the current infrastructure, > by doing minor improvements. There is a certain cost involved with the > SIDR infrastructure. No, we cannot get similar security with current infrastructure, even with MAJOR improvements to the security of the current infrastructure. The structure of the current infrastructure does not permit similar security to what the RPKI provides. Unless, of course, you want to add all RPKI features to the IRR model, so that the IRR becomes the same as the RPKI. Of course, you adopt the cost as well. --Sandy > > I do not think the SSL channel has not been done because it is > unnecessary. I guess there hasn't been an attack on that side of the > infrastructure yet, but these are well known issues/ attacks in other > fields. > > Thanks, > Vishwas > _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 4 08:52:19 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A001A28C7FC; Tue, 4 Mar 2008 08:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.664 X-Spam-Level: X-Spam-Status: No, score=-0.664 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBtDjE+oihUr; Tue, 4 Mar 2008 08:52:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFE0328C6C5; Tue, 4 Mar 2008 08:51:19 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5953028C33D for ; Tue, 4 Mar 2008 08:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6F1ZrpkOdWK for ; Tue, 4 Mar 2008 08:51:15 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.191]) by core3.amsl.com (Postfix) with ESMTP id 0EA7328C6C5 for ; Tue, 4 Mar 2008 08:49:52 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id i36so768111gve.15 for ; Tue, 04 Mar 2008 08:49:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=9f8fEQjfahLWFYmrfZ0DUHPkTOfhlMnVRHVSQugMqCM=; b=kjtXPuZS0oIYjoBcBB5c5LhesqbqkkR1xijD5xRO42PkQEJOzjuVcs2qkFcvUtjw7MPjteL/aTONUvZDpWw7h/ColkXaXbqXIxvQel4xtQfOuR2Crl7L5pqAcAMUyneni7Pv5YcpaPMI13K50wIPy0VbvUJ4/xSlohj3PEHg6P0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=f+y/9gaE87TwzJlHQAol2PwEnRuYhVFnwzEG1Xz96cxPUBNNRiI2uuS/wzX8zsIsUuxxyAHuU5K5bDJdCmiK/osIOuHLsmWLBmJfgOn8jPHFGVX2zFfECyAl3swnB4ODJOrU4B7tUgqINRBbG1O0HJDPvqxe6rbRA7dx3qjvXTU= Received: by 10.142.241.10 with SMTP id o10mr560152wfh.155.1204649381292; Tue, 04 Mar 2008 08:49:41 -0800 (PST) Received: by 10.143.164.14 with HTTP; Tue, 4 Mar 2008 08:49:41 -0800 (PST) Message-ID: <77ead0ec0803040849x7f26aa13hdd8ce7f0489b938b@mail.gmail.com> Date: Tue, 4 Mar 2008 08:49:41 -0800 From: "Vishwas Manral" To: "Sandra Murphy" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <47C4E38E.1070105@bogus.com> <77ead0ec0803020837s16bccee8ledbc9ae1bb60e117@mail.gmail.com> <7C9DBE28-7B7A-4053-85AE-4B954FFEEC57@ca.afilias.info> <77ead0ec0803040714v4235cff2u65bd247694e30570@mail.gmail.com> <5B7F4259-8CAB-4895-8F26-8BFD0CE7C56B@ca.afilias.info> <77ead0ec0803040727n24b68e0fm5650e8fb6c1b1dc@mail.gmail.com> <77ead0ec0803040736t55871ebex445e6fe31d6ac129@mail.gmail.com> <6AAD8CE4-1A16-4C8D-A883-EC5D4D80D2FD@ca.afilias.info> <77ead0ec0803040759p4fad1726m9e175625a13d04a6@mail.gmail.com> Cc: opsec wg mailing list , sidr@ietf.org Subject: Re: [Sidr] [OPSEC] pccw as17557 leak... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi Sandra, You are right RIPE is not the only IRR. The reason I brought up RIPE is because it was mentioned that RIPE provides more secure services. If it is a good model, I would wonder why other IRR cannot do the same. > To be plain, to say SIDR addresses only non-malicious cases is flat out > WRONG. (And sorry for not having pointed that out before, I thought I > did.) Sandra, yes you mentioned it clearly in your mail. Let me put an analogy for the same and let me know if our differences of opinions match, We have 4 glasses on a window and one of them has been made fully bulletproof at a big expense. The point you raise is it protects when you hit against the glass that has been made bulletproof. The point I bring out is that if at a cheaper cost we can harden the glasses it may be a better option. That is what I mean by non-malicious intent. I guess that is the difference of opinion we have. Thanks, Vishwas On Tue, Mar 4, 2008 at 8:34 AM, Sandra Murphy wrote: > > > On Tue, 4 Mar 2008, Vishwas Manral wrote: > > > Hi Joe, > > > > If you saw the mail exchange between Sandra and I, you will notice she > > mentioned the reason they have to go ahead with SIDR even though we > > have tools available from RIPE. What I have been trying to do is to > > figure out weaknesses. in the current infrastructure to get a secure > > behavior. As a first step I found out this weakness and updated RIPE/ > > Daniel about the same. > > Please keep in mind that RIPE is not the only IRR. And RIPE can not > verify authorization for prefixes and ASs outside its range. So improving > RIPE does not buy you what you want. > > > > > > > As we discussed earlier SIDR does not provide a totally secure > > infrastructure. The point here is that SIDR is giving some very basic > > improvements in the security, generally in the non-malicious case. > > Please keep in mind that I have said SIDR does most definitely protect > against malicious attacks for those attacks it is addressing. > > SIDR makes no difference between maliciousness or carelessness in the > attacks it counters. > > There are plenty of malicious and accidental ways to attack routers that > are not in the realm of what SIDR is considering now. Maliciousness is > not the distinguisher here. > > To be plain, to say SIDR addresses only non-malicious cases is flat out > WRONG. (And sorry for not having pointed that out before, I thought I > did.) > > > > > The > > idea is can we get a similar security with the current infrastructure, > > by doing minor improvements. There is a certain cost involved with the > > SIDR infrastructure. > > No, we cannot get similar security with current infrastructure, even with > MAJOR improvements to the security of the current infrastructure. The > structure of the current infrastructure does not permit similar security > to what the RPKI provides. > > Unless, of course, you want to add all RPKI features to the IRR model, so > that the IRR becomes the same as the RPKI. Of course, you adopt the cost > as well. > > --Sandy > > > > > > I do not think the SSL channel has not been done because it is > > unnecessary. I guess there hasn't been an attack on that side of the > > infrastructure yet, but these are well known issues/ attacks in other > > fields. > > > > Thanks, > > Vishwas > > > > > _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Mar 5 21:19:34 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 341B13A6CEF; Wed, 5 Mar 2008 21:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.409 X-Spam-Level: X-Spam-Status: No, score=-100.409 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKyu2fB0qW7y; Wed, 5 Mar 2008 21:19:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B75093A6889; Wed, 5 Mar 2008 21:19:31 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 302273A6BB4; Wed, 5 Mar 2008 21:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffOxhHrMkHg2; Wed, 5 Mar 2008 21:19:28 -0800 (PST) Received: from harbor.brookfield.occnc.com (unknown [69.37.59.172]) by core3.amsl.com (Postfix) with ESMTP id 1C2633A6889; Wed, 5 Mar 2008 21:18:37 -0800 (PST) Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id m265IwVd002532; Thu, 6 Mar 2008 00:18:58 -0500 (EST) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200803060518.m265IwVd002532@harbor.brookfield.occnc.com> To: Joe Abley From: Curtis Villamizar In-reply-to: Your message of "Tue, 04 Mar 2008 10:22:39 EST." <5B7F4259-8CAB-4895-8F26-8BFD0CE7C56B@ca.afilias.info> Date: Thu, 06 Mar 2008 00:18:58 -0500 Cc: opsec wg mailing list , sidr@ietf.org Subject: Re: [Sidr] [OPSEC] pccw as17557 leak... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org In message <5B7F4259-8CAB-4895-8F26-8BFD0CE7C56B@ca.afilias.info> Joe Abley writes: > > > On 4-Mar-2008, at 10:14, Vishwas Manral wrote: > > > I was talking about the RIPE whois and other related tools that RIPE > > provides, when I looked at the link given below: > > http://www.ripe.net/news/study-youtube-hijacking.html > > > > As the tools cannot be accessed using https but using http, the tools > > cannot be used in a guaranteed fashion. We cannot build scripts over > > the tools and feel the information. > > I had no idea they were available over http. Everybody I know who uses > them uses whois. > > As to "cannot build", that doesn't seem to be an opinion shared by the > many ISPs who "have built". > > > Joe > _______________________________________________ > Sidr mailing list > Sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr http://www.ripe.net/db/support/update-reference-manual.pdf Read the abstract and you'll find out what is used for security. Its a bit old but it works. The query or update is in the clear (not encrypted) but can be authenticated with a signature over the contents. Curtis _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Mar 5 21:34:31 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B330628C4D9; Wed, 5 Mar 2008 21:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.413 X-Spam-Level: X-Spam-Status: No, score=-100.413 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1BdLMnbz0gx; Wed, 5 Mar 2008 21:34:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6C823A6CEF; Wed, 5 Mar 2008 21:34:30 -0800 (PST) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B62383A6BB4; Wed, 5 Mar 2008 21:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57RykufjhaGh; Wed, 5 Mar 2008 21:34:29 -0800 (PST) Received: from harbor.brookfield.occnc.com (unknown [69.37.59.172]) by core3.amsl.com (Postfix) with ESMTP id 7C19828C498; Wed, 5 Mar 2008 21:33:41 -0800 (PST) Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id m265Y4To002722; Thu, 6 Mar 2008 00:34:04 -0500 (EST) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200803060534.m265Y4To002722@harbor.brookfield.occnc.com> To: Sandra Murphy From: Curtis Villamizar In-reply-to: Your message of "Tue, 04 Mar 2008 11:34:18 EST." Date: Thu, 06 Mar 2008 00:34:04 -0500 Cc: opsec wg mailing list , sidr@ietf.org Subject: Re: [Sidr] [OPSEC] pccw as17557 leak... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org In message Sandra Murphy writes: > > [---8<---snip---] > > > The > > idea is can we get a similar security with the current infrastructure, > > by doing minor improvements. There is a certain cost involved with the > > SIDR infrastructure. > > No, we cannot get similar security with current infrastructure, even with > MAJOR improvements to the security of the current infrastructure. The > structure of the current infrastructure does not permit similar security > to what the RPKI provides. > > Unless, of course, you want to add all RPKI features to the IRR model, so > that the IRR becomes the same as the RPKI. Of course, you adopt the cost > as well. > > --Sandy Sandy, Would you please enumerate those things that the IRR model does not support after reading RFC2725 and RFC2769. Note that RFC2769 has not been implemented but would provide the missing functionality (ability to authenticate information held in other registries). It also provides efficient replication of databases so anyone can have a local copy of any database of interest to improve query time. I am not advocating going in that direction, simply pointing out that SIDR to a large extent reinvents the wheel. If anything I think SIDR not implementing the full RPSL semantics is deficient. Curtis _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Mar 9 19:45:08 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C99B728C130; Sun, 9 Mar 2008 19:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.985 X-Spam-Level: X-Spam-Status: No, score=-99.985 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyT+8TJPWHvq; Sun, 9 Mar 2008 19:45:03 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D02F33A6BFA; Sun, 9 Mar 2008 19:45:01 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DA0C3A68B9; Sun, 9 Mar 2008 19:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAHUVzEiNyaA; Sun, 9 Mar 2008 19:44:58 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 4266A3A686D; Sun, 9 Mar 2008 19:44:58 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.150.134.25]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JYXyG-0001PT-5m; Sun, 09 Mar 2008 22:42:36 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200803060534.m265Y4To002722@harbor.brookfield.occnc.com> References: <200803060534.m265Y4To002722@harbor.brookfield.occnc.com> Date: Sun, 9 Mar 2008 22:42:45 -0400 To: curtis@occnc.com From: Stephen Kent Cc: opsec wg mailing list , sidr@ietf.org Subject: Re: [Sidr] [OPSEC] pccw as17557 leak... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0234045005==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --===============0234045005== Content-Type: multipart/alternative; boundary="============_-1007005529==_ma============" --============_-1007005529==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 12:34 AM -0500 3/6/08, Curtis Villamizar wrote: >I... > > >Sandy, > >Would you please enumerate those things that the IRR model does not >support after reading RFC2725 and RFC2769. > >Note that RFC2769 has not been implemented but would provide the >missing functionality (ability to authenticate information held in >other registries). It also provides efficient replication of >databases so anyone can have a local copy of any database of interest >to improve query time. > >I am not advocating going in that direction, simply pointing out that >SIDR to a large extent reinvents the wheel. If anything I think SIDR >not implementing the full RPSL semantics is deficient. > >Curtis Curtis, My impression was that 2769 does not address the same set of concerns that the RPKI work is addressing. The RPKI provides a strong, cert-based link between the resource allocation hierarchy and signed objects that attest to resource holdings. The use of ROAs and analogous signed objects (verifiable under the RPKI) enable resource holders to make clearly defined assertions about resources, e.g, the authorization of an AS to originate a route to a prefix. These assertions can be verified without worrying about the integrity of the management of an IRR, e.g., the path via which the object was obtained. 2769 seems to focus on authorization to manage objects in the IRR, a very important but distinct concern. The integrity model seems to emphasize transitive trust (e.g., tracing data integrity back to an authoritative directory), and authorization of manage an object. This is different from the use of signed objects that can be verified through use of an authoritative PKI. (I note that the term PKI does not appear anywhere in the RFC, and the term certificate (or cert) appears only a few times. There are references to use of PGP keys for authenticating a user who wants to manage objects, but that is a very different use of public key crypto.) It is appropriate to examine the intersection of the IRR/RPSL model and the SIDR work to see how the two can fit together, but I disagree with the suggestion that SIDR "reinvents the wheel." SIDR adopts a different initial focus, i.e., defining a profile for certs that represent resource holdings. As we move to introduce additional signed objects, e.g. ROAs and BOAs, then we get closer to some of the functionality of RPSL. Steve --============_-1007005529==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Sidr] [OPSEC] pccw as17557 leak...
At 12:34 AM -0500 3/6/08, Curtis Villamizar wrote:
I...


Sandy,

Would you please enumerate those things that the IRR model does not
support after reading RFC2725 and RFC2769.
Note that RFC2769 has not been implemented but would provide the
missing functionality (ability to authenticate information held in
other registries).  It also provides efficient replication of
databases so anyone can have a local copy of any database of interest
to improve query time.

I am not advocating going in that direction, simply pointing out that
SIDR to a large extent reinvents the wheel.  If anything I think SIDR
not implementing the full RPSL semantics is deficient.
Curtis

Curtis,

My impression was that 2769 does not address the same set of concerns that the RPKI work is addressing.

The RPKI provides a strong, cert-based link between the resource allocation hierarchy and signed objects that attest to resource holdings. The use of ROAs and analogous signed objects (verifiable under the RPKI) enable resource holders to make clearly defined assertions about resources, e.g, the authorization of an AS to originate a route to a prefix. These assertions can be verified without worrying about the integrity of the management of an IRR, e.g., the path via which the object was obtained.

2769 seems to focus on authorization to manage objects in the IRR, a very important but distinct concern.  The integrity model seems to emphasize transitive trust (e.g., tracing data integrity back to an authoritative directory), and authorization of manage an object. This is different from the use of signed objects that can be verified through use of an authoritative PKI. (I note that the term PKI does not appear anywhere in the RFC, and the term certificate (or cert) appears only a few times. There are references to use of PGP keys for authenticating a user who wants to manage objects, but that is a very different use of public key crypto.)

It is appropriate to examine the intersection of the IRR/RPSL model and the SIDR work to see how the two can fit together, but I disagree with the suggestion that SIDR "reinvents the wheel." SIDR adopts a different initial focus, i.e., defining a profile for certs that represent resource holdings. As we move to introduce additional signed objects, e.g. ROAs and BOAs, then  we get closer to some of the functionality of RPSL.

Steve
--============_-1007005529==_ma============-- --===============0234045005== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============0234045005==-- From sidr-bounces@ietf.org Mon Mar 10 12:51:42 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214EA3A68E5; Mon, 10 Mar 2008 12:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.522 X-Spam-Level: X-Spam-Status: No, score=-100.522 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJD84eow6keB; Mon, 10 Mar 2008 12:51:41 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5894F3A695A; Mon, 10 Mar 2008 12:51:41 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 240173A68E5; Mon, 10 Mar 2008 12:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maBGaWNc38Ay; Mon, 10 Mar 2008 12:51:39 -0700 (PDT) Received: from manos.scc.mi.org (manos.scc.mi.org [204.11.140.250]) by core3.amsl.com (Postfix) with ESMTP id 681913A68C6; Mon, 10 Mar 2008 12:51:39 -0700 (PDT) Received: by manos.scc.mi.org (Postfix, from userid 1025) id 52C824E4B0; Mon, 10 Mar 2008 15:49:19 -0400 (EDT) Date: Mon, 10 Mar 2008 15:49:19 -0400 From: Jeffrey Haas To: Sandra Murphy Message-ID: <20080310194919.GA22820@scc.mi.org> References: <77ead0ec0802271712m53e8a1d4sc9cae09ee75686f7@mail.gmail.com> <77ead0ec0802271913u2c032ec2y2d03b73cb36de37f@mail.gmail.com> <77ead0ec0802272031j6d958279tf3028c4096093020@mail.gmail.com> <77ead0ec0802280649k66671fc9s9fc24314963c68a0@mail.gmail.com> <77ead0ec0802280956s3dcff81cx25fd152ea1c798fb@mail.gmail.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: Roland Dobbins , opsec wg mailing list , sidr@ietf.org Subject: Re: [Sidr] [OPSEC] pccw as17557 leak... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Thu, Feb 28, 2008 at 01:34:49PM -0500, Sandra Murphy wrote: > When I say origination of route advertisements, I am not talking about the > ORIGIN attribute in the BGP Update. I'd suggest refering to this as the originating AS. -- Jeff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Mar 10 13:55:12 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E9583A6E1A; Mon, 10 Mar 2008 13:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqNpNXzIJzKe; Mon, 10 Mar 2008 13:55:08 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D536D3A6B07; Mon, 10 Mar 2008 13:55:07 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7DA3A6DD0; Mon, 10 Mar 2008 13:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5Hx2Vd21P8o; Mon, 10 Mar 2008 13:55:04 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id F0FF53A6D4D; Mon, 10 Mar 2008 13:55:03 -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 m2AKqgwL032415; Mon, 10 Mar 2008 15:52:42 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m2AKqgPx021522; Mon, 10 Mar 2008 15:52:42 -0500 Received: from localhost ([130.129.20.112]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Mar 2008 16:52:41 -0400 Date: Mon, 10 Mar 2008 16:52:41 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Curtis Villamizar In-Reply-To: <200803060534.m265Y4To002722@harbor.brookfield.occnc.com> Message-ID: References: <200803060534.m265Y4To002722@harbor.brookfield.occnc.com> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 10 Mar 2008 20:52:41.0703 (UTC) FILETIME=[AED53770:01C882F0] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Mon, 10 Mar 2008 15:52:42 -0500 (CDT) Cc: opsec wg mailing list , sidr@ietf.org Subject: Re: [Sidr] [OPSEC] pccw as17557 leak... X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Thu, 6 Mar 2008, Curtis Villamizar wrote: > > In message > Sandra Murphy writes: >> >> [---8<---snip---] >> << snip >> > > Sandy, > > Would you please enumerate those things that the IRR model does not > support after reading RFC2725 and RFC2769. > > Note that RFC2769 has not been implemented but would provide the > missing functionality (ability to authenticate information held in > other registries). It also provides efficient replication of > databases so anyone can have a local copy of any database of interest > to improve query time. > > I am not advocating going in that direction, simply pointing out that > SIDR to a large extent reinvents the wheel. If anything I think SIDR > not implementing the full RPSL semantics is deficient. > > Curtis > I commented last July on the security model (RPSS) used in RIPE http://www.ietf.org/mail-archive/web/sidr/current/msg00207.html To expand a bit. The model in RPSS has a similar basis as the model used in the RPKI, namely that delegation of a prefix requires authority over a covering prefix - that comes from the inetnum authorization requirement. The RPSS model also insists that the prefix holder is the one who authorizes origination of routes to that prefix. The RPSS model goes further to insist that authorization to originate routes (actually, to create a route object for a prefix) must also be granted by the AS mentioned. In that the authorization model in RPSS is different than the RPKI model. That makes revoking authorization different as well. To delte a route object in RPSS, you need the authorization of both the prefix holder and the AS. (This could cause difficulties if some prefix holder changes providers and wishes to remove the route object, if its former provider is not interested in OK the route object deletion.) RFC2769 addresses the problem (I think) of invalidating inetnums that are derived from an inetnet that gets deleted. (If that is what is meant as "repeating authorization checks".) It seems to me that there is no way to bound the number of database objects that are potentially effected by one object deletion. But the biggest difference is in the trust model. RPSS assumes that the IRR has a way to authenticate the principles - the maintainers. A particular object might have multiple maintainers (of various types) and each can have more than one way to be authenticated. The maintainers authenticate in some way to the IRR and the IRR stores the data. Those referring to the data must have some way to retrieve the data from the IRR that is itself secure. But even with a secure retrieval, the data retrieved carries no hint of the authentication with which it was transmitted to the IRR. You don't know which maintainer placed the info there and you don't know what authentication mechanism was used in accepting the data. No one can authenticate the data except the IRR, and no one can know what assurance to place in the data, aside from a blind "I trust my IRR". There are also issues of staleness of data, as there is no mechanism to state and enforce a validity period. (From reports, stale IRR data played a part in the spread of bogus info in the Con Ed incident last year.) An IRR might go to using the strongest authentication possible, and to accepting signed data and storing the signature. And publishing the certs it assigned to users. That would go pretty far to giving the same assurance of the RPKI. But that's kind of what I meant about adopting the same mechanisms as the RPKI, and therefore the cost --Sandy. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Mar 10 16:03:32 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9567E3A6AAD; Mon, 10 Mar 2008 16:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.746 X-Spam-Level: X-Spam-Status: No, score=-100.746 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaAM7IjslaZg; Mon, 10 Mar 2008 16:03:30 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 876F93A6A81; Mon, 10 Mar 2008 16:03:27 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A05043A6AAD for ; Mon, 10 Mar 2008 16:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2QCoR6bBOkt for ; Mon, 10 Mar 2008 16:03:19 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 744843A6CDB for ; Mon, 10 Mar 2008 16:02:05 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m2AMxgqs027233 for ; Tue, 11 Mar 2008 00:59:42 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m2AMxghp027230 for ; Tue, 11 Mar 2008 00:59:42 +0200 Date: Tue, 11 Mar 2008 00:59:41 +0200 (EET) From: Pekka Savola To: sidr@ietf.org Message-ID: User-Agent: Alpine 1.00 (LRH 882 2007-12-20) MIME-Version: 1.0 X-Virus-Scanned: ClamAV 0.92.1/6188/Sun Mar 9 21:28:13 2008 on otso.netcore.fi X-Virus-Status: Clean Subject: [Sidr] Architecture document: narrowing the scope X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi, As discussed in the meeting, it might make sense to scope the architecture document in such a manner that the document doesn't need to be in progress while the more specific secure routing work goes on. I believe this recasting needs to start from the basics (preferably from the draft name but changing that isn't probably worth it), because the current Title and Abstract can be read to describe secure internet routing infrastructure, which it doesn't really do in the wider interpretation. Replace title: An Infrastructure to Support Secure Internet Routing with e.g.: A Public Key Infrastructure to Describe Route Origination Authorizations I don't see a need to have Secure Internet Routing in the title at all; it is prone to mislead the user. Similar recasting should be applied in Abstract and Introduction, e.g. with Abstract: Abstract This document describes an architecture for an infrastructure to support secure Internet routing. The foundation of this architecture is a public key infrastructure (PKI) that represents the allocation hierarchy of IP address space and Autonomous System Numbers; certificates from this PKI are used to verify signed objects that authorize autonomous systems to originate routes for specified IP address prefixes. The data objects that comprise the PKI, as well as other signed objects necessary for secure routing, are stored and disseminated through a distributed repository system. This document also describes at a high level how this architecture can be used to add security features to common operations such as IP address space allocation and route filter construction. Replace with (also summarizing it a bit): This document describes a public key infrastructure (PKI), the certificates of which could be used to verify signed objects that authorize autonomous systems to originate routes for specified IP address prefixes. These and supporting data objects can be stored and disseminated through a distributed repository system. Possibly also keep the last sentence, but this is a bit of can of worms because these mechanisms have already been described as incomplete (and to avoid this can of worms, some text in section 7.2 and 7.3 could possibly be removed or reworded): This document also describes at a high level how this architecture can be used to add security features to common operations such as IP address space allocation and route filter construction. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Mar 10 16:20:03 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6783A6A39; Mon, 10 Mar 2008 16:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.707 X-Spam-Level: X-Spam-Status: No, score=-100.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2v9WqXlNx3jR; Mon, 10 Mar 2008 16:20:01 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A590928C224; Mon, 10 Mar 2008 16:20:01 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C11A3A6A92 for ; Mon, 10 Mar 2008 16:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+Y67r2Lxowb for ; Mon, 10 Mar 2008 16:20:00 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 1F2BC28C3C8 for ; Mon, 10 Mar 2008 16:20:00 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 4D1AB268037; Mon, 10 Mar 2008 17:17:40 -0600 (MDT) Received: from dhcp-1587.ietf71.ietf.org (division.aa.arbor.net [152.160.38.65]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Mon, 10 Mar 2008 17:17:40 -0600 (MDT) (envelope-from danny@tcb.net) Message-Id: <193EEF5F-FFD4-4635-B6A3-87E6AE77D1AD@tcb.net> From: Danny McPherson To: sidr@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 10 Mar 2008 17:17:24 -0600 References: X-Mailer: Apple Mail (2.919.2) Subject: Re: [Sidr] Architecture document: narrowing the scope X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org [top post only] I agree with Pekka's recommendations here and think recasting it to be far more precise about what problems we're discussing in the architecture document is very important. -danny On Mar 10, 2008, at 4:59 PM, Pekka Savola wrote: > Hi, > > As discussed in the meeting, it might make sense to scope the > architecture document in such a manner that the document doesn't need > to be in progress while the more specific secure routing work goes on. > > I believe this recasting needs to start from the basics (preferably > from the draft name but changing that isn't probably worth it), > because the current Title and Abstract can be read to describe secure > internet routing infrastructure, which it doesn't really do in the > wider interpretation. > > Replace title: > > An Infrastructure to Support Secure Internet Routing > > with e.g.: > > A Public Key Infrastructure to Describe Route Origination > Authorizations > > I don't see a need to have Secure Internet Routing in the title at > all; it is prone to mislead the user. > > Similar recasting should be applied in Abstract and Introduction, e.g. > with Abstract: > > Abstract > > This document describes an architecture for an infrastructure to > support secure Internet routing. The foundation of this > architecture > is a public key infrastructure (PKI) that represents the allocation > hierarchy of IP address space and Autonomous System Numbers; > certificates from this PKI are used to verify signed objects that > authorize autonomous systems to originate routes for specified IP > address prefixes. The data objects that comprise the PKI, as well > as > other signed objects necessary for secure routing, are stored and > disseminated through a distributed repository system. This document > also describes at a high level how this architecture can be used to > add security features to common operations such as IP address space > allocation and route filter construction. > > Replace with (also summarizing it a bit): > > This document describes a public key infrastructure (PKI), the > certificates of which could be used to verify signed objects that > authorize autonomous systems to originate routes for specified IP > address prefixes. These and supporting data objects can be > stored and > disseminated through a distributed repository system. > > Possibly also keep the last sentence, but this is a bit of can of > worms because these mechanisms have already been described as > incomplete (and to avoid this can of worms, some text in section 7.2 > and 7.3 could possibly be removed or reworded): > > This document > also describes at a high level how this architecture can be used to > add security features to common operations such as IP address space > allocation and route filter construction. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > _______________________________________________ > 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 sidr-bounces@ietf.org Mon Mar 10 16:23:29 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C3ED28C24A; Mon, 10 Mar 2008 16:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.564 X-Spam-Level: X-Spam-Status: No, score=-100.564 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJSb61k8uys7; Mon, 10 Mar 2008 16:23:28 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38D0E3A67EF; Mon, 10 Mar 2008 16:23:28 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475553A63CA for ; Mon, 10 Mar 2008 16:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2+e3vuq2+Ob for ; Mon, 10 Mar 2008 16:23:24 -0700 (PDT) Received: from manos.scc.mi.org (manos.scc.mi.org [204.11.140.250]) by core3.amsl.com (Postfix) with ESMTP id 01C2C3A6BFD for ; Mon, 10 Mar 2008 16:23:18 -0700 (PDT) Received: by manos.scc.mi.org (Postfix, from userid 1025) id 1DF344E4B0; Mon, 10 Mar 2008 19:20:58 -0400 (EDT) Date: Mon, 10 Mar 2008 19:20:58 -0400 From: Jeffrey Haas To: sidr@ietf.org Message-ID: <20080310232058.GA25178@scc.mi.org> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: [Sidr] Proposal for ROAs for aggregates X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Consider the case where an ISP has the following prefixes: A1, A2, B, C, D A1 and A2 are aggregateable. B, C and D are not aggregateable. Consider the case where A2, B, C and D are delegated by a given RIR. I would expect to have a ROA for this. This would have a single signature. Similarly, where A1 is delegated from a different ISP, I would expect to have a ROA for this. This would have a single signature. If I wish to generate an aggregate from this, I would expect to have a third ROA that covers the aggregate. This ROA would have signatures from both RIRs. This is effectively the RIRs agreeing that this announcement is permitted to be aggregated. Thus: ROAs would require the ability to have multiple signatures. In the case that there are multiple signatures there is the implication of ownership of the components. Consider the example from RPSL - RFC 2622, section 8.1. -- Jeff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Mar 10 16:24:52 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10AC43A6AED; Mon, 10 Mar 2008 16:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.869 X-Spam-Level: X-Spam-Status: No, score=-100.869 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFYT4rmmW1qW; Mon, 10 Mar 2008 16:24:51 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420E73A67B2; Mon, 10 Mar 2008 16:24:51 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6FE53A6AAD for ; Mon, 10 Mar 2008 16:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+-naN2r79SG for ; Mon, 10 Mar 2008 16:24:49 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 1A8C83A6A92 for ; Mon, 10 Mar 2008 16:24:49 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.150.134.25]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JYrK8-0005v4-5B; Mon, 10 Mar 2008 19:22:28 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 10 Mar 2008 19:22:37 -0400 To: Pekka Savola From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [Sidr] Architecture document: narrowing the scope X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Pekka, I agree that a title with a narrow scope is appropriate, but I believe that you suggested revision is too narrow. The RPKI is broader in scope than just route origination, as Geoff noted. For example, the SBGP and soBGP proposals, which were debated extensively in RPSEC, both address path validation and both rely on the sort of PKI that is being covered in this document. I think some additional wordsmithing on the title and abstract is needed. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Mar 10 16:48:43 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38F7928C164; Mon, 10 Mar 2008 16:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.699 X-Spam-Level: X-Spam-Status: No, score=-100.699 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+9UgxM2tcic; Mon, 10 Mar 2008 16:48:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE983A6AFC; Mon, 10 Mar 2008 16:48:42 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEE493A6AFC for ; Mon, 10 Mar 2008 16:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aY2EIHMIOSKY for ; Mon, 10 Mar 2008 16:48:41 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 3FB863A67A3 for ; Mon, 10 Mar 2008 16:48:41 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 4792F268037; Mon, 10 Mar 2008 17:46:21 -0600 (MDT) Received: from dhcp-1587.ietf71.ietf.org (division.aa.arbor.net [152.160.38.65]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 10 Mar 2008 17:46:21 -0600 (MDT) (envelope-from danny@tcb.net) Message-Id: From: Danny McPherson To: Stephen Kent In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 10 Mar 2008 17:46:05 -0600 References: X-Mailer: Apple Mail (2.919.2) Cc: sidr@ietf.org Subject: Re: [Sidr] Architecture document: narrowing the scope X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Mar 10, 2008, at 5:22 PM, Stephen Kent wrote: > Pekka, > > I agree that a title with a narrow scope is appropriate, but I > believe that you suggested revision is too narrow. The RPKI is > broader in scope than just route origination, as Geoff noted. For > example, the SBGP and soBGP proposals, which were debated > extensively in RPSEC, both address path validation and both rely on > the sort of PKI that is being covered in this document. I think some > additional wordsmithing on the title and abstract is needed. But RPKI provides an infrastructure *to enable those*, OR a static route filter, or any of a number of other things. Listing the array of things that might be done and implying that SIDR itself provides that capability is misleading. -danny _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Mar 10 17:40:10 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82723A6C00; Mon, 10 Mar 2008 17:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.669 X-Spam-Level: X-Spam-Status: No, score=-100.669 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARqWVK++k-+I; Mon, 10 Mar 2008 17:40:08 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD8083A68AA; Mon, 10 Mar 2008 17:40:08 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 560793A68AA for ; Mon, 10 Mar 2008 17:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxxVZyGVpMvU for ; Mon, 10 Mar 2008 17:40:06 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 2BA0D3A67CC for ; Mon, 10 Mar 2008 17:40:06 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.150.132.243]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JYsUx-0000x7-5g; Mon, 10 Mar 2008 20:37:43 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 10 Mar 2008 20:37:52 -0400 To: Danny McPherson From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [Sidr] Architecture document: narrowing the scope X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 5:46 PM -0600 3/10/08, Danny McPherson wrote: >On Mar 10, 2008, at 5:22 PM, Stephen Kent wrote: > >>Pekka, >> >>I agree that a title with a narrow scope is appropriate, but I >>believe that you suggested revision is too narrow. The RPKI is >>broader in scope than just route origination, as Geoff noted. For >>example, the SBGP and soBGP proposals, which were debated >>extensively in RPSEC, both address path validation and both rely on >>the sort of PKI that is being covered in this document. I think some >>additional wordsmithing on the title and abstract is needed. > >But RPKI provides an infrastructure *to enable those*, OR a static >route filter, or any of a number of other things. Listing the array >of things that might be done and implying that SIDR itself provides >that capability is misleading. > >-danny Listing the capabilities that the RPKI enables seems reasonable to me, so long as we don't claim that the near term work items will yield solutions to all of them. The RPKI is not designed to support "any number of things." It is designed to support a set of near and longer term BGP routing security solutions. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Mar 10 22:25:21 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E3F828C1C0; Mon, 10 Mar 2008 22:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.761 X-Spam-Level: X-Spam-Status: No, score=-99.761 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_42=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FaBw0UeBLi3; Mon, 10 Mar 2008 22:25:20 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91B673A6921; Mon, 10 Mar 2008 22:25:20 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6243A6921 for ; Mon, 10 Mar 2008 22:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgIE46+FbdIS for ; Mon, 10 Mar 2008 22:25:18 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 33D7F3A6826 for ; Mon, 10 Mar 2008 22:25:18 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id A0662268037; Mon, 10 Mar 2008 23:22:58 -0600 (MDT) Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (authenticated-user smtp) (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) by dog.tcb.net with SMTP; Mon, 10 Mar 2008 23:22:58 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.150.133; client-port=50498; data-bytes=0 Message-ID: <47D6172F.1040502@castlepoint.net> Date: Mon, 10 Mar 2008 23:22:55 -0600 From: Shane Amante User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Stephen Kent References: In-Reply-To: Cc: sidr@ietf.org Subject: Re: [Sidr] Architecture document: narrowing the scope X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org All, FWIW, I agree with the sentiments echo'ed by Pekka & Danny and would support a narrowing of the Title, etc. to more accurately reflect the present architecture being discussed. -shane Stephen Kent wrote: > At 5:46 PM -0600 3/10/08, Danny McPherson wrote: >> On Mar 10, 2008, at 5:22 PM, Stephen Kent wrote: >> >>> Pekka, >>> >>> I agree that a title with a narrow scope is appropriate, but I >>> believe that you suggested revision is too narrow. The RPKI is >>> broader in scope than just route origination, as Geoff noted. For >>> example, the SBGP and soBGP proposals, which were debated >>> extensively in RPSEC, both address path validation and both rely on >>> the sort of PKI that is being covered in this document. I think some >>> additional wordsmithing on the title and abstract is needed. >> But RPKI provides an infrastructure *to enable those*, OR a static >> route filter, or any of a number of other things. Listing the array >> of things that might be done and implying that SIDR itself provides >> that capability is misleading. >> >> -danny > > Listing the capabilities that the RPKI enables seems reasonable to > me, so long as we don't claim that the near term work items will > yield solutions to all of them. The RPKI is not designed to support > "any number of things." It is designed to support a set of near and > longer term BGP routing security solutions. > > Steve > _______________________________________________ > 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 sidr-bounces@ietf.org Tue Mar 11 06:06:04 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F31B28C404; Tue, 11 Mar 2008 06:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.603 X-Spam-Level: X-Spam-Status: No, score=-100.603 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0JKgMK8rSSm; Tue, 11 Mar 2008 06:06:03 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6477828C3E0; Tue, 11 Mar 2008 06:06:03 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 276E428C3FC for ; Tue, 11 Mar 2008 06:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8BZjHhVM9gi for ; Tue, 11 Mar 2008 06:06:01 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id BD9F828C334 for ; Tue, 11 Mar 2008 06:06:00 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m2BD3b2V014241 for ; Tue, 11 Mar 2008 15:03:37 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m2BD3bjg014237 for ; Tue, 11 Mar 2008 15:03:37 +0200 Date: Tue, 11 Mar 2008 15:03:37 +0200 (EET) From: Pekka Savola To: sidr@ietf.org Message-ID: User-Agent: Alpine 1.00 (LRH 882 2007-12-20) MIME-Version: 1.0 X-Virus-Scanned: ClamAV 0.92.1/6193/Tue Mar 11 01:22:45 2008 on otso.netcore.fi X-Virus-Status: Clean Subject: [Sidr] The necessity for and format of (ISP) CPS X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi, I asked on the mike about the success stories we have had with CPS in other contexts in order to find out who is actually writing these kinds of documents and whether it would be reasonable to expect any of this in future RPKI work. There is probably some need to write at least a minimal statement if you sell certificate authority services. It would be nice to have these documents use a similar format (hence the CPS template) but AFAICS it's also perfectly fine to use your own format; the IETF is not a contract or documentation police :-). On the other hand, if an ISP does not sell those services (but rather is just an end-user and/or provides the service for free for its customers), it's not obvious why most ISPs would be interested in doing a lot of paperwork on this subject. Most ISPs already disclaim any responsibility for pretty much anything that hasn't been explicitly agreed to so not doing any paperwork would be compatible with current practise. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 11 06:17:04 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF74F28C4A6; Tue, 11 Mar 2008 06:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.573 X-Spam-Level: X-Spam-Status: No, score=-100.573 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IODB4sulTNCq; Tue, 11 Mar 2008 06:17:03 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298FD28C53F; Tue, 11 Mar 2008 06:16:47 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA97928C53F for ; Tue, 11 Mar 2008 06:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKEaiNEgrLXN for ; Tue, 11 Mar 2008 06:16:46 -0700 (PDT) Received: from manos.scc.mi.org (manos.scc.mi.org [204.11.140.250]) by core3.amsl.com (Postfix) with ESMTP id CA5BE28C52F for ; Tue, 11 Mar 2008 06:16:23 -0700 (PDT) Received: by manos.scc.mi.org (Postfix, from userid 1025) id 02D0F4E4EA; Tue, 11 Mar 2008 09:14:04 -0400 (EDT) Date: Tue, 11 Mar 2008 09:14:03 -0400 From: Jeffrey Haas To: sidr@ietf.org Message-ID: <20080311131403.GB7974@scc.mi.org> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: [Sidr] Validating the authority of the originating AS to originate a prefix X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Last night during the SIDR session, I made the suggestion that a matching profile should exist for an AS to say what prefixes it intended to announce. While having matching entries from this proposed profile and the ROA may help prevent some malicious announcements with spoofing the origin AS, I think we are better served by having stronger prefix length control in the ROA. Thus I'd like to withdraw the suggestion for an originating AS profile. I'd like express support for the ROA format including prefix-length ranges. Going back to our youtube hijack example, if youtube limited the length of the originating prefix length this mitigates the effects of hijacking of more specific prefixes than are present in the ROA. Viable path validation would likely cover more of these cases. Youtube's AS was likely not adjacent to PCCW's. I believe that SIDR should provide a profile that covers viable paths. -- Jeff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 11 06:29:12 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBF5528C3D6; Tue, 11 Mar 2008 06:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.301 X-Spam-Level: X-Spam-Status: No, score=-100.301 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_22=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeU0YiHa2F2p; Tue, 11 Mar 2008 06:29:11 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17753A6DC3; Tue, 11 Mar 2008 06:29:11 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 867703A69BF for ; Tue, 11 Mar 2008 06:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8m-y5m34DMj for ; Tue, 11 Mar 2008 06:29:09 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id B04D73A68DD for ; Tue, 11 Mar 2008 06:29:09 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.16.169]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JZ4VF-0005G0-5s; Tue, 11 Mar 2008 09:26:49 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 11 Mar 2008 09:26:32 -0400 To: Pekka Savola From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [Sidr] The necessity for and format of (ISP) CPS X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 3:03 PM +0200 3/11/08, Pekka Savola wrote: >Hi, > >I asked on the mike about the success stories we have had with CPS in >other contexts in order to find out who is actually writing these >kinds of documents and whether it would be reasonable to expect any of >this in future RPKI work. > >There is probably some need to write at least a minimal statement if >you sell certificate authority services. It would be nice to have >these documents use a similar format (hence the CPS template) but >AFAICS it's also perfectly fine to use your own format; the IETF is >not a contract or documentation police :-). You're right that you don't have to use the RFC 3647 format, but it is also true that the vast majority of folks who have written a CPS do follow that format. >On the other hand, if an ISP does not sell those services (but rather >is just an end-user and/or provides the service for free for its >customers), it's not obvious why most ISPs would be interested in >doing a lot of paperwork on this subject. Most ISPs already disclaim >any responsibility for pretty much anything that hasn't been >explicitly agreed to so not doing any paperwork would be compatible >with current practise. Even if an ISP is not selling its CA service per se,it is generally agreed that the issuance of certs creates a potential liability. The goal of a CPS (and the RPKI CP) in this context is to give the ISP (and its attorney) greater confidence that it is not assuming liability by acting as a CA in this context. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 11 06:59:54 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D84D328C3CB; Tue, 11 Mar 2008 06:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.761 X-Spam-Level: X-Spam-Status: No, score=-100.761 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ru8igTUx-Dh; Tue, 11 Mar 2008 06:59:53 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB47628C3B7; Tue, 11 Mar 2008 06:59:53 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5D4528C379 for ; Tue, 11 Mar 2008 06:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2AfF4wazOam for ; Tue, 11 Mar 2008 06:59:49 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 019663A6903 for ; Tue, 11 Mar 2008 06:59:49 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id B7005268037; Tue, 11 Mar 2008 07:57:29 -0600 (MDT) Received: from dhcp-11e6.ietf71.ietf.org (dhcp-11e6.ietf71.ietf.org [130.129.17.230]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Tue, 11 Mar 2008 07:57:29 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=130.129.17.230; client-port=55259; syn-fingerprint=65535:54:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: From: Danny McPherson To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 11 Mar 2008 07:57:13 -0600 X-Mailer: Apple Mail (2.919.2) Subject: [Sidr] SIDR Confusion X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org So, one of my concerns with SIDR and it's current scope is this, which I'd very much like some clue about... Today RIRs allocate address space and AS numbers but have NO controls over the routing system. IRRs are used for routing policy specification, and ideally, data in IRRs is used to derive router configuration elements. If SIDR is deployed in some manner, RIRs (and possibly IANA) would have the ability to control what gets routed, and that's a capability that's never existed before, and one that I would suspect operators take considerable issue with. For example, if operators subscribe to a SIDR model and an RIR gets owned and an allocation revoked, or if they happen to make a mistake that results in the same, or some bill non- payment issue arises, or can't publish an update and one expires, or whatever, then the result would be that the associated routing for the concerned prefixes would break. That's never been a threat vector before for ISPs. They wholly control and authorize what they announce. What's worse is regarding who holds those keys. If some country holding the keys (TA) goes to war with another and decides they want to revoke all of their allocations, then ISPs would have zero control over this outside of their own routing domain. One might argue this is part of the reason why DNSSEC raises deployment concerns for some, and has driven folks like .cn to deploy their own root. In my mind, a web of trust model for the routing system better mirrors what we've got today. Allocation authentication is necessary, but just that. IRRs and RPSL or even some back end route server type functions down the road, else we'll never get deployment of this. So, I'm sure suspect I'm missing something here, could folks please help me better understand both incremental deployment models and how the above isn't an issue? Thanks! -danny _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 11 07:13:10 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F6EC3A6C6A; Tue, 11 Mar 2008 07:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.581 X-Spam-Level: X-Spam-Status: No, score=-100.581 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSXD5X2ND+Lq; Tue, 11 Mar 2008 07:13:09 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 811563A69A1; Tue, 11 Mar 2008 07:13:09 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E61728C3AA for ; Tue, 11 Mar 2008 07:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsHkCGMl8KUF for ; Tue, 11 Mar 2008 07:13:06 -0700 (PDT) Received: from manos.scc.mi.org (manos.scc.mi.org [204.11.140.250]) by core3.amsl.com (Postfix) with ESMTP id E277B28C1AF for ; Tue, 11 Mar 2008 07:13:05 -0700 (PDT) Received: by manos.scc.mi.org (Postfix, from userid 1025) id 8D91D4E4A1; Tue, 11 Mar 2008 10:10:46 -0400 (EDT) Date: Tue, 11 Mar 2008 10:10:46 -0400 From: Jeffrey Haas To: Danny McPherson Message-ID: <20080311141046.GD7974@scc.mi.org> References: Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: sidr@ietf.org Subject: Re: [Sidr] SIDR Confusion X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, Mar 11, 2008 at 07:57:13AM -0600, Danny McPherson wrote: > So, I'm sure suspect I'm missing something here, could folks > please help me better understand both incremental deployment > models and how the above isn't an issue? Multiple trust anchors and multiple ROAs. The current ROA model, presuming I'm not misinterpreting the PKI in the drafts, only lets you trace your trust path up one chain. While it'd be nice to trace the trust path to multiple trust anchors from a single ROA, I suspect that the way these ROAs are built wouldn't permit this. See sec 2.4 of the architecture document. -- Jeff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 11 07:21:37 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90B5328C46F; Tue, 11 Mar 2008 07:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.564 X-Spam-Level: X-Spam-Status: No, score=-100.564 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ah8edU2hOohc; Tue, 11 Mar 2008 07:21:33 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AC1728C476; Tue, 11 Mar 2008 07:21:33 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6142628C413 for ; Tue, 11 Mar 2008 07:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78yoDC8zov6G for ; Tue, 11 Mar 2008 07:21:31 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 1F6EC3A6DE5 for ; Tue, 11 Mar 2008 07:21:30 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m2BEJ6aY016309; Tue, 11 Mar 2008 16:19:06 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m2BEJ6g4016306; Tue, 11 Mar 2008 16:19:06 +0200 Date: Tue, 11 Mar 2008 16:19:06 +0200 (EET) From: Pekka Savola To: Jeffrey Haas In-Reply-To: <20080311141046.GD7974@scc.mi.org> Message-ID: References: <20080311141046.GD7974@scc.mi.org> User-Agent: Alpine 1.00 (LRH 882 2007-12-20) MIME-Version: 1.0 X-Virus-Scanned: ClamAV 0.92.1/6193/Tue Mar 11 01:22:45 2008 on otso.netcore.fi X-Virus-Status: Clean Cc: sidr@ietf.org Subject: Re: [Sidr] SIDR Confusion X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, 11 Mar 2008, Jeffrey Haas wrote: > On Tue, Mar 11, 2008 at 07:57:13AM -0600, Danny McPherson wrote: >> So, I'm sure suspect I'm missing something here, could folks >> please help me better understand both incremental deployment >> models and how the above isn't an issue? > > Multiple trust anchors and multiple ROAs. > > The current ROA model, presuming I'm not misinterpreting the PKI in the > drafts, only lets you trace your trust path up one chain. While it'd be > nice to trace the trust path to multiple trust anchors from a single > ROA, I suspect that the way these ROAs are built wouldn't permit this. > > See sec 2.4 of the architecture document. So, instead of using just RIRs as trust anchors, you add every other ISP on the planet as a trust anchor as well (or at least tier1 ISPs and those tier2's which connect to tier1's that don't support RPKI)? Or are you proposing a model where other RIRs or some (currently non-existing from IP addressing perspecive) third parties would be doing additional ROA signing to get this single point of failure? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 11 08:10:42 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 058973A6DA5; Tue, 11 Mar 2008 08:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.587 X-Spam-Level: X-Spam-Status: No, score=-100.587 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAzqA-YYfM-H; Tue, 11 Mar 2008 08:10:40 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55D4D3A6C52; Tue, 11 Mar 2008 08:10:40 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B800C3A6B25 for ; Tue, 11 Mar 2008 08:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0w+EMgFSZjH for ; Tue, 11 Mar 2008 08:10:33 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 3B6E03A6D5A for ; Tue, 11 Mar 2008 08:10:33 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.16.169]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JZ65N-0007BA-3w; Tue, 11 Mar 2008 11:08:13 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 11 Mar 2008 11:07:59 -0400 To: Danny McPherson From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [Sidr] SIDR Confusion X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Danny, The response from Pekka is essentially correct. SIDR decided to issue certs based on the resource allocation hierarchy, because that hierarchy is authoritative for resource allocation, and it requires no introduction of new trust points re attesting to resource allocations (consistent with the RPSEC requirements doc). Each ISP is a relying party in this PKI and, as in every PKI, each RP is empowered to select it own set of trust anchors. Thus ISPs can choose to recognize one another as TAs, in lieu of the default TAs. You can approximate a web of trust model in this fashion, though it is not an exact mapping since X.509 certs do not accommodate multiple signatures. The technical term for the PKI structure you can achieve is a "mesh." The proposal for dealing with stale data (as reflected in the manifest I-D) is to continue to use what you have. Thus the concerns you cite about what happens if anyone (IR or ISP) fails to publish data are not all valid ones. It is fair to note that new or changed data that is not published, or that is not fetched in a timely fashion, could cause ISPs to reject routes based on such changes. Unfortunately, without making change to BGP to carry such data, or providing some parallel distribution mechanism that is similarly timely, ... Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 11 10:32:22 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54F203A6A20; Tue, 11 Mar 2008 10:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.725 X-Spam-Level: X-Spam-Status: No, score=-100.725 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQBR0SihpZvq; Tue, 11 Mar 2008 10:32:21 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E66D93A684E; Tue, 11 Mar 2008 10:31:52 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672A83A684E for ; Tue, 11 Mar 2008 10:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swgG17Vs9DBx for ; Tue, 11 Mar 2008 10:31:50 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 1B61F3A682C for ; Tue, 11 Mar 2008 10:31:50 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id BC9F3268037; Tue, 11 Mar 2008 11:29:30 -0600 (MDT) Received: from dhcp-11e6.ietf71.ietf.org (dhcp-11e6.ietf71.ietf.org [130.129.17.230]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 11 Mar 2008 11:29:30 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=130.129.17.230; client-port=55471; syn-fingerprint=65535:54:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: <4DEF0C27-D92B-45C9-AE14-3EB8D7F26270@tcb.net> From: Danny McPherson To: Stephen Kent In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 11 Mar 2008 11:29:15 -0600 References: X-Mailer: Apple Mail (2.919.2) Cc: sidr@ietf.org Subject: Re: [Sidr] SIDR Confusion X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Mar 11, 2008, at 9:07 AM, Stephen Kent wrote: > > The proposal for dealing with stale data (as reflected in the > manifest I-D) is to continue to use what you have. Thus the concerns > you cite about what happens if anyone (IR or ISP) fails to publish > data are not all valid ones. It is fair to note that new or changed > data that is not published, or that is not fetched in a timely > fashion, could cause ISPs to reject routes based on such changes. > Unfortunately, without making change to BGP to carry such data, or > providing some parallel distribution mechanism that is similarly > timely, ... So to be clear, I didn't intend to propose a web of trust model, although after rereading my text from earlier, my point wasn't clear. I was simply pointing out that with a model such as what's currently proposed RIRs would have a VERY operational role and some authority about what gets routed and what does not. This is a fundamental change from how things work today, where things more approximate a web of trust model - if any. -danny _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 11 11:09:07 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFDE228C250; Tue, 11 Mar 2008 11:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.591 X-Spam-Level: X-Spam-Status: No, score=-100.591 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNNNiqZVAA8h; Tue, 11 Mar 2008 11:09:06 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7314A3A6974; Tue, 11 Mar 2008 11:09:06 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 655483A6974 for ; Tue, 11 Mar 2008 11:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ir22fpxWFBK for ; Tue, 11 Mar 2008 11:09:04 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 5E8443A6A6F for ; Tue, 11 Mar 2008 11:09:04 -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 m2BI0Yi2018826; Tue, 11 Mar 2008 13:00:34 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m2BI0YY8004420; Tue, 11 Mar 2008 13:00:34 -0500 Received: from localhost ([130.129.84.183]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Mar 2008 14:00:32 -0400 Date: Tue, 11 Mar 2008 14:00:27 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Danny McPherson In-Reply-To: <4DEF0C27-D92B-45C9-AE14-3EB8D7F26270@tcb.net> Message-ID: References: <4DEF0C27-D92B-45C9-AE14-3EB8D7F26270@tcb.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 11 Mar 2008 18:00:32.0770 (UTC) FILETIME=[CCB8DE20:01C883A1] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Tue, 11 Mar 2008 13:00:34 -0500 (CDT) Cc: sidr@ietf.org Subject: Re: [Sidr] SIDR Confusion X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, 11 Mar 2008, Danny McPherson wrote: > > On Mar 11, 2008, at 9:07 AM, Stephen Kent wrote: >> >> The proposal for dealing with stale data (as reflected in the >> manifest I-D) is to continue to use what you have. Thus the concerns >> you cite about what happens if anyone (IR or ISP) fails to publish >> data are not all valid ones. It is fair to note that new or changed >> data that is not published, or that is not fetched in a timely >> fashion, could cause ISPs to reject routes based on such changes. >> Unfortunately, without making change to BGP to carry such data, or >> providing some parallel distribution mechanism that is similarly >> timely, ... > > So to be clear, I didn't intend to propose a web of trust model, > although > after rereading my text from earlier, my point wasn't clear. I was > simply > pointing out that with a model such as what's currently proposed RIRs > would have a VERY operational role and some authority about what gets > routed and what does not. This is a fundamental change from how things > work today, where things more approximate a web of trust model - if > any. I understand that the effect of RIRs on routing will be more apparent, but I don't understand saying they have no impact today. For RIRs whose database is a comingled resource and routing database (e.g., RIPE), a billing dispute can effect the RIPE IRR which many people use in routing operations. And the whois is also frequently consulted in making routing decisions. And in any RIR, problems at the RIR level could lead to retraction of your prefix allocation and assignment to someone else. (Recall the social engineering prefix hijacking of a few years back.) That sounds to me like a pretty severe impact on what gets routed. So this might look new, but I don't see that the risk is larger. Of course, there's always the "the relying parties choose what importance to place on the RPKI" caveat. --Sandy > > -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 sidr-bounces@ietf.org Tue Mar 11 11:22:55 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0D428C34E; Tue, 11 Mar 2008 11:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.582 X-Spam-Level: X-Spam-Status: No, score=-100.582 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpTSivRdWpkc; Tue, 11 Mar 2008 11:22:53 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 000E93A6BEB; Tue, 11 Mar 2008 11:22:52 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9703A3A6897 for ; Tue, 11 Mar 2008 11:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fho9SM60oNLi for ; Tue, 11 Mar 2008 11:22:50 -0700 (PDT) Received: from manos.scc.mi.org (manos.scc.mi.org [204.11.140.250]) by core3.amsl.com (Postfix) with ESMTP id 6248A28C422 for ; Tue, 11 Mar 2008 11:22:16 -0700 (PDT) Received: by manos.scc.mi.org (Postfix, from userid 1025) id 268AF4E4F6; Tue, 11 Mar 2008 14:19:57 -0400 (EDT) Date: Tue, 11 Mar 2008 14:19:57 -0400 From: Jeffrey Haas To: Sandra Murphy Message-ID: <20080311181957.GA31671@scc.mi.org> References: <4DEF0C27-D92B-45C9-AE14-3EB8D7F26270@tcb.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: sidr@ietf.org Subject: Re: [Sidr] SIDR Confusion X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, Mar 11, 2008 at 02:00:27PM -0400, Sandra Murphy wrote: > Of course, there's always the "the relying parties choose what importance > to place on the RPKI" caveat. Not to mention it's influence on one's "security metric". (Fake config to drive point.) route-map set-security-pref 10 match ta-map bad-rir set security-pref 1000 exit route-map set-security-pref 20 # Default set security-pref 10 exit This stuff will undoubtedly influence route selection. Just like everything else that affects route selection, there will be knobs. This doesn't worry me. -- Jeff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 11 11:35:09 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A13228C39B; Tue, 11 Mar 2008 11:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.707 X-Spam-Level: X-Spam-Status: No, score=-100.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNlNupZhV69U; Tue, 11 Mar 2008 11:35:05 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C2528C2A6; Tue, 11 Mar 2008 11:35:05 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2ACE3A6810 for ; Tue, 11 Mar 2008 11:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byWaipx54Uxy for ; Tue, 11 Mar 2008 11:35:04 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 28E6128C2A6 for ; Tue, 11 Mar 2008 11:35:04 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id D39CF268037; Tue, 11 Mar 2008 12:32:44 -0600 (MDT) Received: from dhcp-11e6.ietf71.ietf.org (dhcp-11e6.ietf71.ietf.org [130.129.17.230]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 11 Mar 2008 12:32:44 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=130.129.17.230; client-port=55631; syn-fingerprint=65535:54:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: From: Danny McPherson To: Jeffrey Haas In-Reply-To: <20080311181957.GA31671@scc.mi.org> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 11 Mar 2008 12:32:29 -0600 References: <4DEF0C27-D92B-45C9-AE14-3EB8D7F26270@tcb.net> <20080311181957.GA31671@scc.mi.org> X-Mailer: Apple Mail (2.919.2) Cc: sidr@ietf.org Subject: Re: [Sidr] SIDR Confusion X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Mar 11, 2008, at 12:19 PM, Jeffrey Haas wrote: > > Not to mention it's influence on one's "security metric". > > (Fake config to drive point.) > > route-map set-security-pref 10 > match ta-map bad-rir > set security-pref 1000 > exit > route-map set-security-pref 20 > # Default > set security-pref 10 > exit > > This stuff will undoubtedly influence route selection. Just like > everything else that affects route selection, there will be knobs. > This > doesn't worry me. I would note that today policies are only applied when a route is processed upon receipt, not when the policy alone is modified. Therefore, modification of such a policy would require the associated route announcement to be re-advertised (either via BGP route refresh or more memory consuming soft reconfiguration functions, or by reseting a session or actually bouncing the route itself). I.e., changes in status from good to bad based on policy would require re-announcement of the prefix in question if not performed by a security extension to BGP itself. -danny _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 11 11:42:32 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6737C3A6D59; Tue, 11 Mar 2008 11:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.686 X-Spam-Level: X-Spam-Status: No, score=-100.686 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkMicQIO5Opd; Tue, 11 Mar 2008 11:42:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58B973A695E; Tue, 11 Mar 2008 11:42:31 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A8373A692D for ; Tue, 11 Mar 2008 11:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQ+BABA6CHsD for ; Tue, 11 Mar 2008 11:42:26 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id DD6EA28C1C7 for ; Tue, 11 Mar 2008 11:42:01 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id C6B5D268037; Tue, 11 Mar 2008 12:39:42 -0600 (MDT) Received: from dhcp-11e6.ietf71.ietf.org (dhcp-11e6.ietf71.ietf.org [130.129.17.230]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 11 Mar 2008 12:39:42 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=130.129.17.230; client-port=55670; syn-fingerprint=65535:54:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: <8420B089-C6B4-4B19-8678-E8FBED9E695D@tcb.net> From: Danny McPherson To: Sandra Murphy In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 11 Mar 2008 12:39:27 -0600 References: <4DEF0C27-D92B-45C9-AE14-3EB8D7F26270@tcb.net> X-Mailer: Apple Mail (2.919.2) Cc: sidr@ietf.org Subject: Re: [Sidr] SIDR Confusion X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Mar 11, 2008, at 12:00 PM, Sandra Murphy wrote: > > I understand that the effect of RIRs on routing will be more > apparent, but I don't understand saying they have no impact today. They don't actually 'route' anything. > For RIRs whose database is a comingled resource and routing database > (e.g., RIPE), That's different, that's IRRs, not RIRs. > a billing dispute can effect the RIPE IRR which many people use in > routing operations. And the whois is also frequently consulted in > making routing decisions. What? Can you explain what you mean hear? Do you mean someone looks at whois before annoucning a route? That's WAY different than an RIR revoking an allocation and explicitly triggering a withdraw from the routing system. > And in any RIR, problems at the RIR level could lead to retraction > of your prefix allocation and assignment to someone else. (Recall > the social engineering prefix hijacking of a few years back.) That > sounds to me like a pretty severe impact on what gets routed. Yeah, now imagine when operators have no control over this, the attack surface just gained a new dimension. But I would state that today that system flow is not automated. > So this might look new, but I don't see that the risk is larger. Build a threat matrix and add an RIR that now has revocation capabilities that explicitly impact global reachability of a given prefix. That does NOT exist today. > Of course, there's always the "the relying parties choose what > importance to place on the RPKI" caveat. Yes, but what's changed is that peers are now relying on it as well, and therefore may not accept my routes. That's never been in the mix before. -danny _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 11 11:50:47 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4913A6E61; Tue, 11 Mar 2008 11:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.349 X-Spam-Level: X-Spam-Status: No, score=-100.349 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jKpjcGxcwRQ; Tue, 11 Mar 2008 11:50:46 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B74163A6E48; Tue, 11 Mar 2008 11:50:46 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 963243A6897 for ; Tue, 11 Mar 2008 11:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rITfAep3JkIf for ; Tue, 11 Mar 2008 11:50:40 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 118573A6E42 for ; Tue, 11 Mar 2008 11:50:40 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id F0685268037; Tue, 11 Mar 2008 12:48:20 -0600 (MDT) Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (authenticated-user smtp) (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) by dog.tcb.net with SMTP; Tue, 11 Mar 2008 12:48:20 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.150.133; client-port=33848; data-bytes=0 Message-ID: <47D6D3F3.4050605@castlepoint.net> Date: Tue, 11 Mar 2008 12:48:19 -0600 From: Shane Amante User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Sandra Murphy References: <4DEF0C27-D92B-45C9-AE14-3EB8D7F26270@tcb.net> In-Reply-To: Cc: sidr@ietf.org Subject: Re: [Sidr] SIDR Confusion X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Sandy, Sandra Murphy wrote: > > On Tue, 11 Mar 2008, Danny McPherson wrote: > >> On Mar 11, 2008, at 9:07 AM, Stephen Kent wrote: >>> The proposal for dealing with stale data (as reflected in the >>> manifest I-D) is to continue to use what you have. Thus the concerns >>> you cite about what happens if anyone (IR or ISP) fails to publish >>> data are not all valid ones. It is fair to note that new or changed >>> data that is not published, or that is not fetched in a timely >>> fashion, could cause ISPs to reject routes based on such changes. >>> Unfortunately, without making change to BGP to carry such data, or >>> providing some parallel distribution mechanism that is similarly >>> timely, ... >> So to be clear, I didn't intend to propose a web of trust model, >> although >> after rereading my text from earlier, my point wasn't clear. I was >> simply >> pointing out that with a model such as what's currently proposed RIRs >> would have a VERY operational role and some authority about what gets >> routed and what does not. This is a fundamental change from how things >> work today, where things more approximate a web of trust model - if >> any. > > I understand that the effect of RIRs on routing will be more apparent, but > I don't understand saying they have no impact today. > > For RIRs whose database is a comingled resource and routing database > (e.g., RIPE), a billing dispute can effect the RIPE IRR which many people > use in routing operations. And the whois is also frequently consulted in > making routing decisions. I think you may be confusing "registration services", (e.g.: acquiring & registering PI space and/or ASN's), vs. IRR -- Internet Routing Registries. The IRR's directly affect routing policy on ISP networks, because SP's build prefix, etc. filters off them. And, nearly all IRR's are *free* to the public, specifically: ARIN, RIPE (according to info publicly available on their Web sites) ... even Level 3. Thus, non-payment for "registration services" (not IRR services) is going to have little to no impact on routing policy on provider's networks. If my understanding is correct, the model being discussed here is dramatically different than the way that IRR's are operated & used today. -shane > And in any RIR, problems at the RIR level could lead to retraction of your > prefix allocation and assignment to someone else. (Recall the social > engineering prefix hijacking of a few years back.) That sounds to me like > a pretty severe impact on what gets routed. > > So this might look new, but I don't see that the risk is larger. > > Of course, there's always the "the relying parties choose what importance > to place on the RPKI" caveat. > > --Sandy > >> -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 _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 11 13:45:45 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19A5A28C2F6; Tue, 11 Mar 2008 13:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.722 X-Spam-Level: X-Spam-Status: No, score=-100.722 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nWqgIqDhSoi; Tue, 11 Mar 2008 13:45:40 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 869793A6E50; Tue, 11 Mar 2008 13:45:01 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3C8F28C243 for ; Tue, 11 Mar 2008 13:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKxw8q0Tg-Hm for ; Tue, 11 Mar 2008 13:45:00 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id B6CE43A68E2 for ; Tue, 11 Mar 2008 13:42:28 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.150.133.93]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JZBGa-0004Ln-69; Tue, 11 Mar 2008 16:40:09 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4DEF0C27-D92B-45C9-AE14-3EB8D7F26270@tcb.net> References: <4DEF0C27-D92B-45C9-AE14-3EB8D7F26270@tcb.net> Date: Tue, 11 Mar 2008 16:40:17 -0400 To: Danny McPherson From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [Sidr] SIDR Confusion X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 11:29 AM -0600 3/11/08, Danny McPherson wrote: >On Mar 11, 2008, at 9:07 AM, Stephen Kent wrote: >> >>The proposal for dealing with stale data (as reflected in the >>manifest I-D) is to continue to use what you have. Thus the >>concerns you cite about what happens if anyone (IR or ISP) fails to >>publish data are not all valid ones. It is fair to note that new or >>changed data that is not published, or that is not fetched in a >>timely fashion, could cause ISPs to reject routes based on such >>changes. Unfortunately, without making change to BGP to carry such >>data, or providing some parallel distribution mechanism that is >>similarly timely, ... > >So to be clear, I didn't intend to propose a web of trust model, although >after rereading my text from earlier, my point wasn't clear. I was simply >pointing out that with a model such as what's currently proposed RIRs >would have a VERY operational role and some authority about what gets >routed and what does not. This is a fundamental change from how things >work today, where things more approximate a web of trust model - if >any. > >-danny Danny, OK, thanks for the clarification. if nobody checks announcements against any reference(s), then the system can be very responsive, but also vulnerable. I am told that some set of ISPs download IRR data from multiple sources, on a daily basis, and use that data in constructing router filters. For those ISPs, route object info changes that are missed in a periodic download can result in the sort of problems you cite. For the ISPs who adopt this model, this appears to be an acceptable, if imperfect, tradeoff. Nobody can mandate that all ISPs make use of ROA, BOA, and other data that will become available from the SIDR work. If enough folks find it useful, them presumably it will be used, otherwise not. Also, the static distribution of info via a repository system is not the ultimate goal of the SIDR work, just the starting point. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 11 14:16:21 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AA263A6BED; Tue, 11 Mar 2008 14:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.617 X-Spam-Level: X-Spam-Status: No, score=-100.617 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMQBzoz1My46; Tue, 11 Mar 2008 14:16:20 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C48FB28C224; Tue, 11 Mar 2008 14:16:18 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42AD53A6B95 for ; Tue, 11 Mar 2008 14:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RUsWorlZDbZ for ; Tue, 11 Mar 2008 14:16:14 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 0C9163A6B4A for ; Tue, 11 Mar 2008 14:16:13 -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 m2BLDibB029089; Tue, 11 Mar 2008 16:13:44 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m2BLDimT017862; Tue, 11 Mar 2008 16:13:44 -0500 Received: from localhost ([130.129.84.183]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Mar 2008 17:13:44 -0400 Date: Tue, 11 Mar 2008 17:13:41 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Shane Amante In-Reply-To: <47D6D3F3.4050605@castlepoint.net> Message-ID: References: <4DEF0C27-D92B-45C9-AE14-3EB8D7F26270@tcb.net> <47D6D3F3.4050605@castlepoint.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 11 Mar 2008 21:13:44.0234 (UTC) FILETIME=[C9C5E8A0:01C883BC] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Tue, 11 Mar 2008 16:13:44 -0500 (CDT) Cc: sidr@ietf.org Subject: Re: [Sidr] SIDR Confusion X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, 11 Mar 2008, Shane Amante wrote: > Sandy, > > Sandra Murphy wrote: >> >> On Tue, 11 Mar 2008, Danny McPherson wrote: >> >>> On Mar 11, 2008, at 9:07 AM, Stephen Kent wrote: >>>> The proposal for dealing with stale data (as reflected in the >>>> manifest I-D) is to continue to use what you have. Thus the concerns >>>> you cite about what happens if anyone (IR or ISP) fails to publish >>>> data are not all valid ones. It is fair to note that new or changed >>>> data that is not published, or that is not fetched in a timely >>>> fashion, could cause ISPs to reject routes based on such changes. >>>> Unfortunately, without making change to BGP to carry such data, or >>>> providing some parallel distribution mechanism that is similarly >>>> timely, ... >>> So to be clear, I didn't intend to propose a web of trust model, >>> although >>> after rereading my text from earlier, my point wasn't clear. I was >>> simply >>> pointing out that with a model such as what's currently proposed RIRs >>> would have a VERY operational role and some authority about what gets >>> routed and what does not. This is a fundamental change from how things >>> work today, where things more approximate a web of trust model - if >>> any. >> >> I understand that the effect of RIRs on routing will be more apparent, but >> I don't understand saying they have no impact today. >> >> For RIRs whose database is a comingled resource and routing database (e.g., >> RIPE), a billing dispute can effect the RIPE IRR which many people use in >> routing operations. And the whois is also frequently consulted in making >> routing decisions. > > I think you may be confusing "registration services", (e.g.: acquiring & > registering PI space and/or ASN's), vs. IRR -- Internet Routing Registries. > The IRR's directly affect routing policy on ISP networks, because SP's build > prefix, etc. filters off them. And, nearly all IRR's are *free* to the > public, specifically: ARIN, RIPE (according to info publicly available on > their Web sites) ... even Level 3. Thus, non-payment for "registration > services" (not IRR services) is going to have little to no impact on routing > policy on provider's networks. > I understand the difference. However, ARIN looks to see if the registrant of a inetnum in their IRR is the same person as the POC for the allocated resource, as the authorization to register the inetnum. So I have extrapolated from there to the belief that if they yank your resource they would yank the associated inetnum. (If they didn't, it would be a bad thing that should be fixed.) And RIPE has a co-mingled registry/routing policy database. Their representation of a registry allocation of space is the inetnum (as I understand their database). So yanking an address means the inetnum disappears in RIPE as well. (Again, if they didn't, it would be a bad thing that you would want them to fix, yes?) And that has got to effect routing policies somewhere. Of course, there are the individual ISP's IRRs and the RADB etc. Which have no authentication/authorization model at all much less one based on the registry allocation of resources. And yet people use them, go figure. --Sandy > If my understanding is correct, the model being discussed here is > dramatically different than the way that IRR's are operated & used today. > > -shane > _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Mar 12 10:19:16 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F24123A692B; Wed, 12 Mar 2008 10:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.729 X-Spam-Level: X-Spam-Status: No, score=-100.729 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6ISiOAjc7IN; Wed, 12 Mar 2008 10:19:15 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BF583A6A40; Wed, 12 Mar 2008 10:19:15 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C363A6A40 for ; Wed, 12 Mar 2008 10:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaM3Gjbdb7jh for ; Wed, 12 Mar 2008 10:19:13 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id A1CB63A6941 for ; Wed, 12 Mar 2008 10:19:13 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.16.169]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JZUZR-0001QN-5P; Wed, 12 Mar 2008 13:16:53 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <2672FE09-4E11-49C2-B3A2-F864A7F6E3F9@asgaard.org> References: <2672FE09-4E11-49C2-B3A2-F864A7F6E3F9@asgaard.org> Date: Wed, 12 Mar 2008 12:54:11 -0400 To: Christopher LILJENSTOLPE From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [Sidr] The necessity for and format of (ISP) CPS X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 12:13 AM -0700 3/12/08, Christopher LILJENSTOLPE wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Greetings, > > That may be the case, however, that is sort-of like saying >that the IETF is protecting yourself from yourself. no, its not. The IETF (via PKIX) published the overall format for a CP or a CPS years ago, later updated it, and this format is widely adopted. What I said was that an organization operating a PKI can reduce its potential liability by publishing a CPS consistent with this format. > I would assume that anyone spinning up a PKI infrastructure >would have some internal legal review. Their lawyers will, I'm >sure, have something to say about that. yes, and a lawyer who is knowledgeable about PKI issues will generally recommend publishing a CPS based on RFC 3647. > Maybe publish a BCP that states that a CPS or it's equivalent >MAY be recommended, but if someone want's to fly by dead-reckoning, >more power to them... > It's not clear that the IETF should offer this sort of legal advice. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Mar 12 12:49:33 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACBA328C63E; Wed, 12 Mar 2008 12:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.617 X-Spam-Level: X-Spam-Status: No, score=-100.617 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdiLl+5vDWyF; Wed, 12 Mar 2008 12:49:29 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3DCE28C518; Wed, 12 Mar 2008 12:49:29 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3FD328C3E8 for ; Wed, 12 Mar 2008 12:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADT06xyYwR3G for ; Wed, 12 Mar 2008 12:49:23 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 3ED573A6EE6 for ; Wed, 12 Mar 2008 12:49:23 -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 m2CJl4NS014572 for ; Wed, 12 Mar 2008 14:47:04 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m2CJl4oP012535 for ; Wed, 12 Mar 2008 14:47:04 -0500 Received: from localhost ([130.129.22.51]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Mar 2008 15:47:03 -0400 Date: Wed, 12 Mar 2008 15:47:04 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 12 Mar 2008 19:47:04.0046 (UTC) FILETIME=[D8A1F0E0:01C88479] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Wed, 12 Mar 2008 14:47:04 -0500 (CDT) Subject: [Sidr] rsync discussion history X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Here's my promised message about the rsync discussions in and outside the working group. The sidr mailing list shows exchanges about rsync around Oct 30-31, 2006 with Joe Abley expressing concerns about interop of different implementations, and 28-31 Mar 07 starting with William Leibzon expressing concerns about IESG/IETF process. Those message also include messages describing the features that are needed and how rsync satisfies those. That's about it. But the discussion during meetings and in private exchnages has snowballed: (1) rsync is not a URI OK, we'll get it registered based on the RFC (2) rsync is not an rfc and the author is not interested in making it one OK, we'll do a third party registration based on the spec (3) there is no stable spec for rsync (aka "the code is the spec") OK, we'll register the URI based on ... the code? (if we can) (4) there are (a few) wg concerns about non-interoperability of independent implementations, due to lack of spec OK, we'll presume that everyone uses the open-source implementation. (5) rsync has gone through some non-backward-compatible version changes in the past. OK, we'll hope the rsync project doesn't do that again, else new versions of rsync with non-backward compatible features would require a flag day. You may recall a mention in Monday's meeting of license difficulties for commercial implementations. At this point in the history, I discovered that the rsync open source project used a license that forbid charging for any code that included their code. That would have made commercial implementations problematic. However, I just discovered that with the announcement of rsync 3.0 on March 1, 2008 they have moved from GPL version 2 to GPL version 3: http://www.samba.org/rsync/GPL.html From a first glance through, I can not find similar text that would prohibit charging for code that includes their code. People who are used to reading these GPL licences should take a look to see if you see limits on commercial use of the rsync code. So the difficulty about commercial implementations could be OBE. --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Mar 13 12:06:37 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 625D13A6F2A; Thu, 13 Mar 2008 12:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.618 X-Spam-Level: X-Spam-Status: No, score=-100.618 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQk+v4Bqat5u; Thu, 13 Mar 2008 12:06:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AF3E3A6C33; Thu, 13 Mar 2008 12:02:22 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 282A428C873 for ; Thu, 13 Mar 2008 12:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OI-lwoWPnWPL for ; Thu, 13 Mar 2008 12:02:20 -0700 (PDT) Received: from mail.enyo.de (mail.enyo.de [IPv6:2001:14b0:202:1::a7]) by core3.amsl.com (Postfix) with ESMTP id 75EF928C88E for ; Thu, 13 Mar 2008 12:01:28 -0700 (PDT) Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1JZsdr-00045S-3y; Thu, 13 Mar 2008 19:59:03 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1JZsdq-000746-Ij; Thu, 13 Mar 2008 19:59:02 +0100 From: Florian Weimer To: Sandra Murphy References: Date: Thu, 13 Mar 2008 19:59:02 +0100 In-Reply-To: (Sandra Murphy's message of "Wed, 12 Mar 2008 15:47:04 -0400 (Eastern Daylight Time)") Message-ID: <87lk4mih6x.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Cc: sidr@ietf.org Subject: Re: [Sidr] rsync discussion history X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org * Sandra Murphy: > (3) there is no stable spec for rsync (aka "the code is the spec") > > OK, we'll register the URI based on ... the code? (if we can) I wonder if rsync is the right protocol anyway. To me, this looks more like an application of zsync or WebDAV (with VCDIFF, RFC 3284, for transmitting delta updates). zsync is similar to rsync, but doesn't need special server support. It should also be easier to standardize. It's not clear to me if you need rsync's capability for transmitting collections of files. In that case, neither approach willl help you, but you should be aware that the current rsync implementation binds significant resources on the server side, particularly for large directory trees. To a lesser extent, this also applies to the single-file mode. > At this point in the history, I discovered that the rsync open source > project used a license that forbid charging for any code that included > their code. That would have made commercial implementations problematic. > > However, I just discovered that with the announcement of rsync 3.0 on > March 1, 2008 they have moved from GPL version 2 to GPL version 3: > http://www.samba.org/rsync/GPL.html The charging scheme (you may create derivative works if you give downstream users the same permissions as we gave to you) hasn't changed, so this will not make a difference. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Mar 14 06:35:34 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE903A6F56; Fri, 14 Mar 2008 06:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.711 X-Spam-Level: X-Spam-Status: No, score=-100.711 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUJfZ8fwiXdk; Fri, 14 Mar 2008 06:35:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E70583A6CB1; Fri, 14 Mar 2008 06:35:32 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817453A680F for ; Fri, 14 Mar 2008 06:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsfI0IBSuVsM for ; Fri, 14 Mar 2008 06:35:28 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id A92313A67E2 for ; Fri, 14 Mar 2008 06:35:28 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.27.82.86]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JaA1y-0006N8-5R; Fri, 14 Mar 2008 09:33:06 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <2672FE09-4E11-49C2-B3A2-F864A7F6E3F9@asgaard.org> Date: Fri, 14 Mar 2008 09:29:27 -0400 To: Christopher LILJENSTOLPE From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [Sidr] The necessity for and format of (ISP) CPS X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 1:36 PM -0700 3/13/08, Christopher LILJENSTOLPE wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Stephen, > > What I was saying is that, if this IS for the protection of >the the individual entity hosting the PKI, then to issue a CPS is >their call, not ours to specify as a standards action. > > Either people will grok the risk and make a judgement, or not >grok the risk and still make a judgement. Therefore, suggesting >that someone embarking on SIDR may want to consider a CPS with their >powers-that-be is probably a good-thing(TM) - which is what BCPs are >for. >However, saying that it is part of doing SIDR, is probably not germane. > > Now if we are not saying that CPS is required for SIDR, then >I humbly withdraw my comments and blame it on a mis-parsing on my >part. > > Chris Chris, I do not believe that anyone is suggesting that to be a CA in the RPKI you MUST issue a CPS. I believe that each RIR will issue its own CPS, and the handful of NIRs that exists probably will as well. As for ISPs, bigger ones probably will, but smaller ones may not. In general an entity operating a CA (other that for purely internal use) should publish a CPS, and RFC 3647 provides a generally accepted outline for writing a CP or a CPS. If an ISP acting as a CA in the RPKI decides to issue a CPS, we can make life easier for them by having a published template as a (non-normative) starting point. Our experience in doing this in the RIR space certainly suggests that is the case, i.e, the work I did for APNIC to help complete their CPS benefited greatly from having the RIR CPS template as a starting point. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Mar 14 06:40:22 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5041728C8FE; Fri, 14 Mar 2008 06:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.596 X-Spam-Level: X-Spam-Status: No, score=-100.596 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruw-KeUqXndA; Fri, 14 Mar 2008 06:40:21 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FC953A6F56; Fri, 14 Mar 2008 06:40:21 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55A073A6F56 for ; Fri, 14 Mar 2008 06:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4x-eN7BvRwXX for ; Fri, 14 Mar 2008 06:40:20 -0700 (PDT) Received: from manos.scc.mi.org (manos.scc.mi.org [204.11.140.250]) by core3.amsl.com (Postfix) with ESMTP id 9E8943A6F34 for ; Fri, 14 Mar 2008 06:40:20 -0700 (PDT) Received: by manos.scc.mi.org (Postfix, from userid 1025) id 9B3F34E4A7; Fri, 14 Mar 2008 09:38:03 -0400 (EDT) Date: Fri, 14 Mar 2008 09:38:03 -0400 From: Jeffrey Haas To: Florian Weimer Message-ID: <20080314133803.GD29868@scc.mi.org> References: <87lk4mih6x.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <87lk4mih6x.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.9i Cc: sidr@ietf.org Subject: Re: [Sidr] rsync discussion history X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Florian, On Thu, Mar 13, 2008 at 07:59:02PM +0100, Florian Weimer wrote: > It's not clear to me if you need rsync's capability for transmitting > collections of files. This is the major advantage of using rsync. When you must sync a large number of files, it is *very* efficient. For our purposes, we just care that we can gather all of the necessary files. This can be as simple as downloading the latest manifest and then fetching all changed files within the manifest. This was one of the reasons I had suggested a "last updated" value for the items in the manifest at the microphone at the SIDR meeting. -- Jeff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Mar 14 11:31:37 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E883A6EA0; Fri, 14 Mar 2008 11:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.443 X-Spam-Level: X-Spam-Status: No, score=-100.443 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TEM3ciCvnji; Fri, 14 Mar 2008 11:31:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8FDF3A6CB1; Fri, 14 Mar 2008 11:31:32 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF03D3A6A19 for ; Fri, 14 Mar 2008 11:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXQVu1-MFDhQ for ; Fri, 14 Mar 2008 11:31:28 -0700 (PDT) Received: from aep-us-dc-01.aep-net.com (unknown [63.139.155.212]) by core3.amsl.com (Postfix) with ESMTP id 175EE3A6B61 for ; Fri, 14 Mar 2008 11:31:28 -0700 (PDT) Received: from [172.16.50.201] ([76.110.31.20]) by aep-us-dc-01.aep-net.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Mar 2008 14:29:11 -0400 Message-Id: <4D22EF37-FCF2-48BB-889F-8FE8C17A1B04@aepnetworks.com> From: "Michele (Mike) Hjorleifsson" To: sidr@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 14 Mar 2008 14:29:10 -0400 References: X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 14 Mar 2008 18:29:11.0097 (UTC) FILETIME=[4C2A0290:01C88601] Subject: [Sidr] Rsync X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org SWYgdGhlIGNvbnNlbnN1cyBpcyB0byBnbyBmb3J3YXJkIHdpdGggcnN5bmMsIG1heSBpIHN1Z2dl c3Qgd2Ugc3RhcnQgIAp3aXRoIHJzeW5jIG92ZXIgc3NoIHNvIHRoYXQgdGhlIGluZm9ybWF0aW9u IGJlaW5nIHRyYW5zZmVycmVkIGlzICAKc29tZXdoYXQgcHJvdGVjdGVkCnRoZSBhY2NlcHRpbmcg c2l0ZXMgY2FuIHNldHVwIGtleSBhbmQgaG9zdCBiYXNlZCBhdXRoZW50aWNhdGlvbiB0byBhZGQg IAphIGxheWVyIG9mIHNlY3VyaXR5IGFzIHdlbGwuCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KTWlrZSBIam9ybGVpZnNzb24KVVMgVGVjaG5pY2FsIFNhbGVzIE1h bmFnZXIKQUVQIE5ldHdvcmtzLCBJbmMKMzQ3IEVsaXphYmV0aCBBdmVudWUKU29tZXJzZXQsIE5K IDA4NzczClBoOiA3MzItNjUyLTUyNTcKRW06IG1pa2VoQGFlcG5ldHdvcmtzLmNvbQrvo78gQXBw bGUgQUNUQyAgCXx8ICAgIAlNaWNyb3NvZnQgTUNQL01DVC9NUFMKQ2l0cml4IENDQS9DQ0kgIAl8 fCAJTm92ZWxsIExpbnV4IEVuZ2luZWVyCkZUT0NDIENlcnRpZmllZCBWT0lQIFRlY2huaWNpYW4K CgoKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClNp ZHIgbWFpbGluZyBsaXN0ClNpZHJAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zaWRyCg== From sidr-bounces@ietf.org Fri Mar 14 13:15:58 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2BAE28C0DE; Fri, 14 Mar 2008 13:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.797 X-Spam-Level: X-Spam-Status: No, score=-100.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNtkgZI8BOCo; Fri, 14 Mar 2008 13:15:57 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C794D3A680C; Fri, 14 Mar 2008 13:15:57 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 730B73A690E for ; Fri, 14 Mar 2008 13:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXbeI8dIP2XN for ; Fri, 14 Mar 2008 13:15:55 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id C57353A67B6 for ; Fri, 14 Mar 2008 13:15:54 -0700 (PDT) Received: from [192.168.1.105] (ip70-187-235-142.dc.dc.cox.net [70.187.235.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id C149FD5F2D for ; Sat, 15 Mar 2008 06:13:36 +1000 (EST) Message-Id: From: Terry Manderson To: sidr@ietf.org In-Reply-To: <20080314133803.GD29868@scc.mi.org> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 15 Mar 2008 06:13:32 +1000 References: <87lk4mih6x.fsf@mid.deneb.enyo.de> <20080314133803.GD29868@scc.mi.org> X-Mailer: Apple Mail (2.919.2) Subject: Re: [Sidr] rsync discussion history X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org I'm not going to go back through the process of discussing the merits and downfalls of RSYNC or any other competing protocol or service that might be used as the fetch mechanism. Looking at the draft: section 3.9.7 "Other access method URIs that reference the same location MAY also be included in the value sequence of this extension. The ordering of URIs in this sequence reflect the subject's relative preferences for access methods, with the first method in the sequence being the most preferred." The last sentence is important, I'll not regurgitate the various discussions I had with the authors to get that in play, instead simply to point out: 1) You need an initial and effective service to code to, and to allow a base common denominator for development and deployment. 2) Where and how you collect the information is by far a secondary concern to the realisation that the information simply needs to exist and at least accessible by 1) So to clarify, you can indeed assert another URI to put in play, and preference it over RSYNC, but still have RSYNC as the lowest common denominator for base level interoperability. Terry On 14/03/2008, at 11:38 PM, Jeffrey Haas wrote: > Florian, > > On Thu, Mar 13, 2008 at 07:59:02PM +0100, Florian Weimer wrote: >> It's not clear to me if you need rsync's capability for transmitting >> collections of files. > > This is the major advantage of using rsync. When you must sync a > large > number of files, it is *very* efficient. > > For our purposes, we just care that we can gather all of the necessary > files. This can be as simple as downloading the latest manifest and > then fetching all changed files within the manifest. This was one of > the reasons I had suggested a "last updated" value for the items in > the > manifest at the microphone at the SIDR meeting. > > -- Jeff > _______________________________________________ > Sidr mailing list > Sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr -- Terry Manderson email: terry@apnic.net Network Operations Manager, APNIC sip: info@voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sat Mar 15 13:10:21 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD673A6854; Sat, 15 Mar 2008 13:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.653 X-Spam-Level: X-Spam-Status: No, score=-100.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QDOg81QwjFb; Sat, 15 Mar 2008 13:10:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC38C3A6C86; Sat, 15 Mar 2008 13:10:06 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 528243A69E3 for ; Sat, 15 Mar 2008 13:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZtHa53485Zf for ; Sat, 15 Mar 2008 13:09:59 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id BCE9D3A6854 for ; Sat, 15 Mar 2008 13:09:58 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 0ACC12680D7; Sat, 15 Mar 2008 14:07:43 -0600 (MDT) Received: from [192.168.1.103] (VDSL-151-118-146-11.DNVR.QWEST.NET [151.118.146.11]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Sat, 15 Mar 2008 14:07:42 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=151.118.146.11; client-port=50725; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0 Message-Id: <4FF6AA6E-2BCC-488F-A747-E846CAE15D7B@tcb.net> From: Danny McPherson To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 15 Mar 2008 14:07:41 -0600 References: X-Mailer: Apple Mail (2.919.2) Subject: [Sidr] Fwd: Kenyan Route Hijack X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Thought folks here might find this interesting. -danny Begin forwarded message: > From: Danny McPherson > Date: March 15, 2008 2:06:53 PM MDT > To: Felix Bako > Cc: NANOG NANOG > Subject: Re: Kenyan Route Hijack > > > A bit more analysis of this at the moment, and a few recommendations > and related pointers is available here: > > http://tinyurl.com/2nqg2a > > -danny _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Mar 17 04:11:52 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7383D28C2DD; Mon, 17 Mar 2008 04:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.475 X-Spam-Level: X-Spam-Status: No, score=-101.475 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYMKg8nlouGa; Mon, 17 Mar 2008 04:11:48 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BBEE3A6A76; Mon, 17 Mar 2008 04:11:48 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76E433A6B1F for ; Mon, 17 Mar 2008 04:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3m-fvNbMkLs for ; Mon, 17 Mar 2008 04:11:46 -0700 (PDT) Received: from postman.ripe.net (postman.ripe.net [193.0.19.2]) by core3.amsl.com (Postfix) with ESMTP id 60E863A6A76 for ; Mon, 17 Mar 2008 04:11:46 -0700 (PDT) Received: by postman.ripe.net (Postfix, from userid 4008) id 008C323FAD; Mon, 17 Mar 2008 12:09:28 +0100 (CET) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id 03B5023F70; Mon, 17 Mar 2008 12:09:23 +0100 (CET) Received: from [127.0.0.1] (chimp.ripe.net [193.0.1.199]) by herring.ripe.net (Postfix) with ESMTP id EB7D32F583; Mon, 17 Mar 2008 12:09:22 +0100 (CET) Message-ID: <47DE5161.3030104@ripe.net> Date: Mon, 17 Mar 2008 12:09:21 +0100 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: "Michele (Mike) Hjorleifsson" References: <4D22EF37-FCF2-48BB-889F-8FE8C17A1B04@aepnetworks.com> In-Reply-To: <4D22EF37-FCF2-48BB-889F-8FE8C17A1B04@aepnetworks.com> X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.137243 / -4.4 X-RIPE-Signature: 1dd133c6b47be6e7b44f18a1743a0b8d Cc: sidr@ietf.org Subject: Re: [Sidr] Rsync X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org SGksCgpJIHdvbmRlciB3aGF0IHRoZSBiZW5lZml0IHdvdWxkIGJlPyAoSSBjYW4ndCBwYXJzZSAi c29tZXdoYXQgcHJvdGVjdGVkIikKCldlIG5lZWQgbm8gZW5jcnlwdGlvbiBvbiB0aGUgY2hhbm5l bCwgYXMgYWxsIHRoZSBwdWJsaXNoZWQgaW5mb3JtYXRpb24gaXMgCnB1YmxpYy4gVGhlIG9iamVj dHMgdGhlbXNlbHZlcyAobWFuaWZlc3RzLCBjZXJ0cywgQ1JMcywgUk9BcywgLi4uKSBhcmUgCnNp Z25lZCBzbyB5b3UgY2FuIGNhdGNoIHRhbXBlcmluZy4gRmluYWxseSwgdGhlIGV4aXN0ZW5jZSBv ZiBtYW5pZmVzdCAKcHJvdmlkZXMgc291cmNlIGF1dGhlbnRpY2F0aW9uLiBTbyB0aGVyZSBkb2Vz IG5vdCBzZWVtIHRvIGJlIGFueSBhZHZhbnRhZ2VzIApmb3IgdGhpcy4KCk9UT0gsIHlvdSAqd291 bGQqIGhhdmUgdG8gaW5jb3Jwb3JhdGUgYSBjb21wbGV0ZWx5IHNlcGFyYXRlIFBLSSBpbiBvcmRl ciB0byAKYXV0aGVudGljYXRlIGhvc3RzIChwb3RlbnRpYWxseSB0aG91c2FuZHMgb2YgdGhlbSku CgpSb2JlcnQKCgoKTWljaGVsZSAoTWlrZSkgSGpvcmxlaWZzc29uIHdyb3RlOgo+IElmIHRoZSBj b25zZW5zdXMgaXMgdG8gZ28gZm9yd2FyZCB3aXRoIHJzeW5jLCBtYXkgaSBzdWdnZXN0IHdlIHN0 YXJ0ICAKPiB3aXRoIHJzeW5jIG92ZXIgc3NoIHNvIHRoYXQgdGhlIGluZm9ybWF0aW9uIGJlaW5n IHRyYW5zZmVycmVkIGlzICAKPiBzb21ld2hhdCBwcm90ZWN0ZWQKPiB0aGUgYWNjZXB0aW5nIHNp dGVzIGNhbiBzZXR1cCBrZXkgYW5kIGhvc3QgYmFzZWQgYXV0aGVudGljYXRpb24gdG8gYWRkICAK PiBhIGxheWVyIG9mIHNlY3VyaXR5IGFzIHdlbGwuCj4gCj4gCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBNaWtlIEhqb3JsZWlmc3Nvbgo+IFVTIFRlY2huaWNh bCBTYWxlcyBNYW5hZ2VyCj4gQUVQIE5ldHdvcmtzLCBJbmMKPiAzNDcgRWxpemFiZXRoIEF2ZW51 ZQo+IFNvbWVyc2V0LCBOSiAwODc3Mwo+IFBoOiA3MzItNjUyLTUyNTcKPiBFbTogbWlrZWhAYWVw bmV0d29ya3MuY29tCj4g76O/IEFwcGxlIEFDVEMgIAl8fCAgICAJTWljcm9zb2Z0IE1DUC9NQ1Qv TVBTCj4gQ2l0cml4IENDQS9DQ0kgIAl8fCAJTm92ZWxsIExpbnV4IEVuZ2luZWVyCj4gRlRPQ0Mg Q2VydGlmaWVkIFZPSVAgVGVjaG5pY2lhbgo+IAo+IAo+IAo+IAo+IAo+IAo+IAo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gU2lkciBtYWlsaW5nIGxp c3QKPiBTaWRyQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaWRyCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpT aWRyIG1haWxpbmcgbGlzdApTaWRyQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2lkcgo= From sidr-bounces@ietf.org Mon Mar 17 09:34:49 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E38A028C487; Mon, 17 Mar 2008 09:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.652 X-Spam-Level: X-Spam-Status: No, score=-100.652 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qixwCUWOBKwG; Mon, 17 Mar 2008 09:34:44 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65D5928C43B; Mon, 17 Mar 2008 09:34:44 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 680FE28C453 for ; Mon, 17 Mar 2008 09:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVh3QvOiR8dk for ; Mon, 17 Mar 2008 09:34:39 -0700 (PDT) Received: from asgaard.org (odin.asgaard.org [204.29.149.34]) by core3.amsl.com (Postfix) with ESMTP id 8CC6F28C42E for ; Mon, 17 Mar 2008 09:34:39 -0700 (PDT) Received: from [10.10.20.197] (mail.wovensystems.com [70.143.0.241]) by asgaard.org (Postfix) with ESMTP id 1E01CF43F48; Mon, 17 Mar 2008 16:32:21 +0000 (UTC) Message-Id: <94B12CFC-BC92-4C80-8832-6D12C7DC3469@cdl.asgaard.org> From: Christopher LILJENSTOLPE To: Stephen Kent In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 17 Mar 2008 08:20:03 -0700 References: <2672FE09-4E11-49C2-B3A2-F864A7F6E3F9@asgaard.org> X-Pgp-Agent: GPGMail d51 (Leopard) X-Mailer: Apple Mail (2.919.2) Cc: sidr@ietf.org Subject: Re: [Sidr] The necessity for and format of (ISP) CPS X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQpIYXNoOiBTSEExCgpPayAtIEkgd2l0 aGRyYXcgbXkgY29tbWVudHMuLi4uCgoJY2hyaXMKCk9uIDE0IE1hciAyMDA4LCBhdCAwNi4yOSwg U3RlcGhlbiBLZW50IHdyb3RlOgoKPiBBdCAxOjM2IFBNIC0wNzAwIDMvMTMvMDgsIENocmlzdG9w aGVyIExJTEpFTlNUT0xQRSB3cm90ZToKPj4gLS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0Ut LS0tLQo+PiBIYXNoOiBTSEExCj4+Cj4+IFN0ZXBoZW4sCj4+Cj4+IAlXaGF0IEkgd2FzIHNheWlu ZyBpcyB0aGF0LCBpZiB0aGlzIElTIGZvciB0aGUgcHJvdGVjdGlvbiBvZiB0aGUgIAo+PiB0aGUg aW5kaXZpZHVhbCBlbnRpdHkgaG9zdGluZyB0aGUgUEtJLCB0aGVuIHRvIGlzc3VlIGEgQ1BTIGlz IHRoZWlyICAKPj4gY2FsbCwgbm90IG91cnMgdG8gc3BlY2lmeSBhcyBhIHN0YW5kYXJkcyBhY3Rp b24uCj4+Cj4+IAlFaXRoZXIgcGVvcGxlIHdpbGwgZ3JvayB0aGUgcmlzayBhbmQgbWFrZSBhIGp1 ZGdlbWVudCwgb3Igbm90IGdyb2sgIAo+PiB0aGUgcmlzayBhbmQgc3RpbGwgbWFrZSBhIGp1ZGdl bWVudC4gIFRoZXJlZm9yZSwgc3VnZ2VzdGluZyB0aGF0ICAKPj4gc29tZW9uZSBlbWJhcmtpbmcg b24gU0lEUiBtYXkgd2FudCB0byBjb25zaWRlciBhIENQUyB3aXRoIHRoZWlyICAKPj4gcG93ZXJz LXRoYXQtYmUgaXMgcHJvYmFibHkgYSBnb29kLXRoaW5nKFRNKSAtIHdoaWNoIGlzIHdoYXQgQkNQ cyAgCj4+IGFyZSBmb3IuICBIb3dldmVyLCBzYXlpbmcgdGhhdCBpdCBpcyBwYXJ0IG9mIGRvaW5n IFNJRFIsIGlzICAKPj4gcHJvYmFibHkgbm90IGdlcm1hbmUuCj4+Cj4+IAlOb3cgaWYgd2UgYXJl IG5vdCBzYXlpbmcgdGhhdCBDUFMgaXMgcmVxdWlyZWQgZm9yIFNJRFIsIHRoZW4gSSAgCj4+IGh1 bWJseSB3aXRoZHJhdyBteSBjb21tZW50cyBhbmQgYmxhbWUgaXQgb24gYSBtaXMtcGFyc2luZyBv biBteSBwYXJ0Lgo+Pgo+PiAJQ2hyaXMKPgo+IENocmlzLAo+Cj4gSSBkbyBub3QgYmVsaWV2ZSB0 aGF0IGFueW9uZSBpcyBzdWdnZXN0aW5nIHRoYXQgdG8gYmUgYSBDQSBpbiB0aGUgIAo+IFJQS0kg eW91IE1VU1QgaXNzdWUgYSBDUFMuIEkgYmVsaWV2ZSB0aGF0IGVhY2ggUklSIHdpbGwgaXNzdWUg aXRzICAKPiBvd24gQ1BTLCBhbmQgdGhlIGhhbmRmdWwgb2YgTklScyB0aGF0IGV4aXN0cyBwcm9i YWJseSB3aWxsIGFzIHdlbGwuICAKPiBBcyBmb3IgSVNQcywgYmlnZ2VyIG9uZXMgcHJvYmFibHkg d2lsbCwgYnV0IHNtYWxsZXIgb25lcyBtYXkgbm90LiBJbiAgCj4gZ2VuZXJhbCBhbiBlbnRpdHkg b3BlcmF0aW5nIGEgQ0EgKG90aGVyIHRoYXQgZm9yIHB1cmVseSBpbnRlcm5hbCAgCj4gdXNlKSBz aG91bGQgcHVibGlzaCBhIENQUywgYW5kIFJGQyAzNjQ3IHByb3ZpZGVzIGEgZ2VuZXJhbGx5ICAK PiBhY2NlcHRlZCBvdXRsaW5lIGZvciB3cml0aW5nIGEgQ1Agb3IgYSBDUFMuCj4KPiBJZiBhbiBJ U1AgYWN0aW5nIGFzIGEgQ0EgaW4gdGhlIFJQS0kgZGVjaWRlcyB0byBpc3N1ZSBhIENQUywgd2Ug Y2FuICAKPiBtYWtlIGxpZmUgZWFzaWVyIGZvciB0aGVtIGJ5IGhhdmluZyBhIHB1Ymxpc2hlZCB0 ZW1wbGF0ZSBhcyBhIChub24tIAo+IG5vcm1hdGl2ZSkgc3RhcnRpbmcgcG9pbnQuIE91ciBleHBl cmllbmNlIGluIGRvaW5nIHRoaXMgaW4gdGhlIFJJUiAgCj4gc3BhY2UgY2VydGFpbmx5IHN1Z2dl c3RzIHRoYXQgaXMgdGhlIGNhc2UsIGkuZSwgdGhlIHdvcmsgSSBkaWQgZm9yICAKPiBBUE5JQyB0 byBoZWxwIGNvbXBsZXRlIHRoZWlyIENQUyBiZW5lZml0ZWQgZ3JlYXRseSBmcm9tIGhhdmluZyB0 aGUgIAo+IFJJUiBDUFMgdGVtcGxhdGUgYXMgYSBzdGFydGluZyBwb2ludC4KPgo+IFN0ZXZlCj4K Ci0gLS0tCuadjuafr+edvwpDaGVjayBteSBQR1Aga2V5IGhlcmU6Cmh0dHA6Ly9wZ3AubWl0LmVk dToxMTM3MS9wa3MvbG9va3VwP29wPWdldCZzZWFyY2g9MHhDQjY3NTkzQgoKCgoKLS0tLS1CRUdJ TiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRRWNCQUVCQWdBR0JRSkgzb3dqQUFvSkVHbXgyTXQvK0l3 L3JyRUgvMDRSWWp1OXJENm5uK0gvY1pCZXpkMjYKNU9ERGVBQkRReGVyMXVVd2d3a3I1SlFkdkJT anFQcHNmODM0N2tpSGFDdE4vYTZDazJrYnA0M0pRaWlyeEdPTAovNVU0a2RxSm5weFQ5ZlJYMmt5 N2FUUDJXSWsxamtCVjJaT09WRCtrQnFnOEdsellIdStveVNELzBFL0Qwa2k4Ck8zckNGRG5qVnBL V0JVWHl1VXFqQkJDQ2ZVdlBsMEhrWEc4amJpcHJDSmFtbXlvUDhUbkQ5b0ZTYnVHSmxJT2IKaEVr ZE9VZm9zbzQ0NXVYaTBWZ2VCY25SYmgxZmI0QUM4ZTdUcjNkTGQ2d1pwOUxEMHh0ek1Fazd4SDVT VUdTRgp6L3VCZ283a0VzWWs4d3ZDdHJwSTBqenVqeWswQWFibFBaRTFSbkRGbGg1c05UNXphNlNL VzhjcllUTjAwZTg9Cj0xY1hZCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpTaWRyIG1haWxpbmcgbGlzdApT aWRyQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lkcgo= From sidr-bounces@ietf.org Mon Mar 17 10:41:17 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDF963A6E2F; Mon, 17 Mar 2008 10:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.533 X-Spam-Level: X-Spam-Status: No, score=-100.533 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L214ak2J-B0m; Mon, 17 Mar 2008 10:41:17 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B0AB3A6B9C; Mon, 17 Mar 2008 10:41:17 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56C553A6E02 for ; Mon, 17 Mar 2008 10:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zcdVJZA-A-I for ; Mon, 17 Mar 2008 10:41:15 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 547143A6A8E for ; Mon, 17 Mar 2008 10:41:15 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA06.westchester.pa.mail.comcast.net with comcast id 2GU21Z02D0ldTLk5602K00; Mon, 17 Mar 2008 17:38:05 +0000 Received: from TONYLTM9XP ([155.53.43.187]) by OMTA04.westchester.pa.mail.comcast.net with comcast id 2Hej1Z00542Hpm33Q00000; Mon, 17 Mar 2008 17:38:56 +0000 X-Authority-Analysis: v=1.0 c=1 a=R5CK-gZN47JdSI7YCLQA:9 a=7gUpI08rn5417_nlrWFUB3Ituf4A:4 a=WuK_CZDBSqoA:10 From: "Tony Li" To: "'Robert Kisteleki'" , "'Michele \(Mike\) Hjorleifsson'" References: <4D22EF37-FCF2-48BB-889F-8FE8C17A1B04@aepnetworks.com> <47DE5161.3030104@ripe.net> Date: Mon, 17 Mar 2008 10:38:44 -0700 Message-ID: <004201c88855$c77f8540$6e00a8c0@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <47DE5161.3030104@ripe.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciIH2KelcctCoacQDGj54k6w3Po8wANj19Q Cc: sidr@ietf.org Subject: Re: [Sidr] Rsync X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org One benefit would be a secure, automatic exchanges without cleartext authentication. Tony |I wonder what the benefit would be? (I can't parse "somewhat |protected") | |We need no encryption on the channel, as all the published |information is |public. The objects themselves (manifests, certs, CRLs, ROAs, ...) are |signed so you can catch tampering. Finally, the existence of manifest |provides source authentication. So there does not seem to be |any advantages |for this. | |OTOH, you *would* have to incorporate a completely separate |PKI in order to |authenticate hosts (potentially thousands of them). _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Mar 17 11:53:09 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E699F28C1CB; Mon, 17 Mar 2008 11:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.447 X-Spam-Level: X-Spam-Status: No, score=-100.447 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZ9iT7APNcMh; Mon, 17 Mar 2008 11:53:09 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6123A6E3D; Mon, 17 Mar 2008 11:53:09 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B71B3A6DF2 for ; Mon, 17 Mar 2008 11:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlslpOn-Zkil for ; Mon, 17 Mar 2008 11:53:06 -0700 (PDT) Received: from aep-us-dc-01.aep-net.com (unknown [63.139.155.212]) by core3.amsl.com (Postfix) with ESMTP id 2DD953A6E3D for ; Mon, 17 Mar 2008 11:53:05 -0700 (PDT) Received: from [10.1.136.48] ([166.192.178.233]) by aep-us-dc-01.aep-net.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Mar 2008 14:50:47 -0400 References: <4D22EF37-FCF2-48BB-889F-8FE8C17A1B04@aepnetworks.com> <47DE5161.3030104@ripe.net> <004201c88855$c77f8540$6e00a8c0@ad.redback.com> Message-Id: <40094356-09D7-4453-9D78-277C3B1AB7F4@aepnetworks.com> From: "Michele (Mike) Hjorleifsson" To: "" In-Reply-To: <004201c88855$c77f8540$6e00a8c0@ad.redback.com> X-Mailer: iPhone Mail (4A102) Mime-Version: 1.0 (iPhone Mail 4A102) Date: Mon, 17 Mar 2008 14:50:36 -0400 X-OriginalArrivalTime: 17 Mar 2008 18:50:48.0745 (UTC) FILETIME=[D0DCA190:01C8885F] Cc: "" Subject: Re: [Sidr] Rsync X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org You could also limit which hosts can rsync Michele (Mike) Hjorleifsson On Mar 17, 2008, at 13:38, "Tony Li" wrote: > > One benefit would be a secure, automatic exchanges without cleartext > authentication. > > Tony > > > |I wonder what the benefit would be? (I can't parse "somewhat > |protected") > | > |We need no encryption on the channel, as all the published > |information is > |public. The objects themselves (manifests, certs, CRLs, ROAs, ...) > are > |signed so you can catch tampering. Finally, the existence of manifest > |provides source authentication. So there does not seem to be > |any advantages > |for this. > | > |OTOH, you *would* have to incorporate a completely separate > |PKI in order to > |authenticate hosts (potentially thousands of them). > _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Mar 17 13:09:04 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE7653A6E85; Mon, 17 Mar 2008 13:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.677 X-Spam-Level: X-Spam-Status: No, score=-100.677 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBPYQrJjoniM; Mon, 17 Mar 2008 13:09:03 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB01228C439; Mon, 17 Mar 2008 13:08:53 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8611E3A6E81 for ; Mon, 17 Mar 2008 13:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clk-5fzauSfu for ; Mon, 17 Mar 2008 13:08:47 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id F3F7328C480 for ; Mon, 17 Mar 2008 13:07:34 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JbLa9-00026K-5R; Mon, 17 Mar 2008 16:05:17 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <94B12CFC-BC92-4C80-8832-6D12C7DC3469@cdl.asgaard.org> References: <2672FE09-4E11-49C2-B3A2-F864A7F6E3F9@asgaard.org> <94B12CFC-BC92-4C80-8832-6D12C7DC3469@cdl.asgaard.org> Date: Mon, 17 Mar 2008 15:41:46 -0400 To: Christopher LILJENSTOLPE From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [Sidr] The necessity for and format of (ISP) CPS X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 8:20 AM -0700 3/17/08, Christopher LILJENSTOLPE wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Ok - I withdraw my comments.... > > chris no problem. I suspect this was not adequately clear, or others would have jumped into the discussion. We'll make sure it is clear in the next round of revisions to the CPS. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Mar 17 16:57:59 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA6D13A6EAB; Mon, 17 Mar 2008 16:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdIeb8me6cGz; Mon, 17 Mar 2008 16:57:58 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB0673A6E9C; Mon, 17 Mar 2008 16:57:58 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D5F3A6E6C for ; Mon, 17 Mar 2008 16:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttcY4mozHjjB for ; Mon, 17 Mar 2008 16:57:57 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 215353A6870 for ; Mon, 17 Mar 2008 16:57:57 -0700 (PDT) Received: from [202.12.29.217] (dhcp217.apnic.net [202.12.29.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id AE1C2D5F2D; Tue, 18 Mar 2008 09:55:39 +1000 (EST) Message-ID: <47DF04FB.9020103@apnic.net> Date: Tue, 18 Mar 2008 09:55:39 +1000 From: Robert Loomans Organization: APNIC - http://www.apnic.net/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: tony.li@tony.li References: <4D22EF37-FCF2-48BB-889F-8FE8C17A1B04@aepnetworks.com> <47DE5161.3030104@ripe.net> <004201c88855$c77f8540$6e00a8c0@ad.redback.com> In-Reply-To: <004201c88855$c77f8540$6e00a8c0@ad.redback.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=C6B3AE7E; url=http://robert.loomans.org/0xC6B3AE7E.asc Cc: "'Michele \(Mike\) Hjorleifsson'" , sidr@ietf.org Subject: Re: [Sidr] Rsync X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1914696406==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1914696406== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040001000803000508020806" This is a cryptographically signed message in MIME format. --------------ms040001000803000508020806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tony Li wrote: > One benefit would be a secure, automatic exchanges without cleartext > authentication. There is no authentication for the repositories. They are publicly, anonymously available. Every party who wants to check one of your assertions (ROA, etc) needs to be able to retrieve the appropriate certificates, CRLs, etc. Rob -- Robert Loomans Email: robertl@apnic.net Senior Software Engineer, APNIC Phone: +61 7 3858 3100 http://www.apnic.net Fax: +61 7 3858 3199 --------------ms040001000803000508020806 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCC BW8wggRXoAMCAQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UE ChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5h Z2VyQGFwbmljLm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNV BAYTAkFQMREwDwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTAL BgNVBAUTBDg5NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjF QP4OmyB73NE86ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs 02JKEd4Kwap6eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH 0PvpZNWiV3uBqhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR 7r2SJDQ8SXiUJy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+ uyZcsqAE7VVX0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAA MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklD IENsaWVudCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsG A1UdIwSBszCBsIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFV MQ4wDAYDVQQKEwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQD EyVBUE5JQyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkB FhNjYW1hbmFnZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0 MB4GA1UdEgQXMBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0 cHM6Ly93d3cuYXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0 dHBzOi8vd3d3LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZo dHRwczovL3d3dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOC AQEAhtnqJUiql+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq 32x4R8YHDgfUwq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiC gPx/wQ72Eyj6DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgk f2Qk5n8RiNEpzzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKT H3fAz9RQC3zprZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjCCBW8wggRXoAMC AQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMx GzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmlj Lm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNVBAYTAkFQMREw DwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTALBgNVBAUTBDg5 NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjFQP4OmyB73NE8 6ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs02JKEd4Kwap6 eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH0PvpZNWiV3uB qhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR7r2SJDQ8SXiU Jy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+uyZcsqAE7VVX 0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAAMBEGCWCGSAGG +EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklDIENsaWVudCBD ZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsGA1UdIwSBszCB sIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFVMQ4wDAYDVQQK EwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQDEyVBUE5JQyBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkBFhNjYW1hbmFn ZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0MB4GA1UdEgQX MBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0cHM6Ly93d3cu YXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0dHBzOi8vd3d3 LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwczovL3d3 dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAhtnqJUiq l+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq32x4R8YHDgfU wq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiCgPx/wQ72Eyj6 DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgkf2Qk5n8RiNEp zzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKTH3fAz9RQC3zp rZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjGCA8YwggPCAgEBMIGVMIGOMQsw CQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNl czEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAG CSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmljLm5ldAICIwMwCQYFKw4DAhoFAKCCAgUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwMzE3MjM1NTM5WjAj BgkqhkiG9w0BCQQxFgQUXsniJa7QOodfzgSWdRacLw0SQyMwUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgaYGCSsGAQQBgjcQBDGBmDCBlTCBjjELMAkGA1UEBhMCQVUxDjAMBgNV BAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNVBAMTJUFQTklD IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0BCQEWE2NhbWFu YWdlckBhcG5pYy5uZXQCAiMDMIGoBgsqhkiG9w0BCRACCzGBmKCBlTCBjjELMAkGA1UEBhMC QVUxDjAMBgNVBAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNV BAMTJUFQTklDIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0B CQEWE2NhbWFuYWdlckBhcG5pYy5uZXQCAiMDMA0GCSqGSIb3DQEBAQUABIIBAIwDGsRJMDQS f2JIh5um4DvaZaJyOCSR77STktDgxVdBCj5mbDmwVUPPPO+T5vL71t8icCnIxL3iTDFwGyWP rnVm6IUcnnkrM2C3kzrK2NImAb/VY+aQ8UEhmcPp6AI/Y7ugWUCT0BkUU3DdnIDm2xnovblq Iy0nLTBiAZa+rFeS1+W2FKSsEqMHnChq7b0EljAEu0sEGbn4AcbjWBnKw1z/ypBKlcX7GxFY pjLQjDm6nFBWcckLUQrlQ2kZ8WUfT6qgH16tf+JQeE0FDzKoiM+2jNHXi5Kn35EH08cVBQqu 2KZ/gcC5JCVXU8jvunmdAqVqJUqS8I1YvQm8Ng03XboAAAAAAAA= --------------ms040001000803000508020806-- --===============1914696406== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============1914696406==-- From sidr-bounces@ietf.org Mon Mar 17 17:00:15 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06AD13A6EB0; Mon, 17 Mar 2008 17:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.677 X-Spam-Level: X-Spam-Status: No, score=-100.677 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i14C2mAnhAgZ; Mon, 17 Mar 2008 17:00:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3492E3A6EA7; Mon, 17 Mar 2008 17:00:14 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95B363A6EA5 for ; Mon, 17 Mar 2008 17:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTjTLw156U97 for ; Mon, 17 Mar 2008 17:00:11 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 8C4CA3A6BFE for ; Mon, 17 Mar 2008 17:00:11 -0700 (PDT) Received: from [202.12.29.217] (dhcp217.apnic.net [202.12.29.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 9486FD5F2D; Tue, 18 Mar 2008 09:57:54 +1000 (EST) Message-ID: <47DF0582.3010700@apnic.net> Date: Tue, 18 Mar 2008 09:57:54 +1000 From: Robert Loomans Organization: APNIC - http://www.apnic.net/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: "Michele (Mike) Hjorleifsson" References: <4D22EF37-FCF2-48BB-889F-8FE8C17A1B04@aepnetworks.com> <47DE5161.3030104@ripe.net> <004201c88855$c77f8540$6e00a8c0@ad.redback.com> <40094356-09D7-4453-9D78-277C3B1AB7F4@aepnetworks.com> In-Reply-To: <40094356-09D7-4453-9D78-277C3B1AB7F4@aepnetworks.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=C6B3AE7E; url=http://robert.loomans.org/0xC6B3AE7E.asc Cc: "" Subject: Re: [Sidr] Rsync X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1350698984==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1350698984== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020601040508070808010301" This is a cryptographically signed message in MIME format. --------------ms020601040508070808010301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Michele (Mike) Hjorleifsson wrote: > You could also limit which hosts can rsync That would be defeating the intent. The objects in the repositories are intended for public consumption. There is no way to predict who will want access and from which hosts they will run their tools. Rob -- Robert Loomans Email: robertl@apnic.net Senior Software Engineer, APNIC Phone: +61 7 3858 3100 http://www.apnic.net Fax: +61 7 3858 3199 --------------ms020601040508070808010301 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCC BW8wggRXoAMCAQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UE ChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5h Z2VyQGFwbmljLm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNV BAYTAkFQMREwDwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTAL BgNVBAUTBDg5NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjF QP4OmyB73NE86ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs 02JKEd4Kwap6eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH 0PvpZNWiV3uBqhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR 7r2SJDQ8SXiUJy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+ uyZcsqAE7VVX0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAA MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklD IENsaWVudCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsG A1UdIwSBszCBsIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFV MQ4wDAYDVQQKEwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQD EyVBUE5JQyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkB FhNjYW1hbmFnZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0 MB4GA1UdEgQXMBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0 cHM6Ly93d3cuYXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0 dHBzOi8vd3d3LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZo dHRwczovL3d3dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOC AQEAhtnqJUiql+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq 32x4R8YHDgfUwq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiC gPx/wQ72Eyj6DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgk f2Qk5n8RiNEpzzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKT H3fAz9RQC3zprZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjCCBW8wggRXoAMC AQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMx GzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmlj Lm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNVBAYTAkFQMREw DwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTALBgNVBAUTBDg5 NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjFQP4OmyB73NE8 6ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs02JKEd4Kwap6 eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH0PvpZNWiV3uB qhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR7r2SJDQ8SXiU Jy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+uyZcsqAE7VVX 0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAAMBEGCWCGSAGG +EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklDIENsaWVudCBD ZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsGA1UdIwSBszCB sIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFVMQ4wDAYDVQQK EwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQDEyVBUE5JQyBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkBFhNjYW1hbmFn ZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0MB4GA1UdEgQX MBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0cHM6Ly93d3cu YXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0dHBzOi8vd3d3 LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwczovL3d3 dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAhtnqJUiq l+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq32x4R8YHDgfU wq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiCgPx/wQ72Eyj6 DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgkf2Qk5n8RiNEp zzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKTH3fAz9RQC3zp rZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjGCA8YwggPCAgEBMIGVMIGOMQsw CQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNl czEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAG CSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmljLm5ldAICIwMwCQYFKw4DAhoFAKCCAgUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwMzE3MjM1NzU0WjAj BgkqhkiG9w0BCQQxFgQUVF7t8luNon+0WoQ5TfL/DMOET0EwUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgaYGCSsGAQQBgjcQBDGBmDCBlTCBjjELMAkGA1UEBhMCQVUxDjAMBgNV BAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNVBAMTJUFQTklD IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0BCQEWE2NhbWFu YWdlckBhcG5pYy5uZXQCAiMDMIGoBgsqhkiG9w0BCRACCzGBmKCBlTCBjjELMAkGA1UEBhMC QVUxDjAMBgNVBAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNV BAMTJUFQTklDIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0B CQEWE2NhbWFuYWdlckBhcG5pYy5uZXQCAiMDMA0GCSqGSIb3DQEBAQUABIIBAMRBpJp2lh+R GgJXflCwGXUBcsQJu9c6kYrQMNJjekUo3h8yDFFWtkKYCzEH+VhQ7j5WQIA8sgWu5tP3ehvx TgaPqaEgKsXgbDGSmcR+7NFV1IG4XX2KEuniic5ZIxLeW0QYqo1/aFFtAmHupwH2imF+0ziq V70sT7KTFz7Mjli5i4ReVKqa0ellqltJIB+Vmr5SmV9SGMh1qMyWs/2L0zfI6xSjvywcY9c1 itAfq9lhrUW+PPHzdBe8peN0rIkIZgMIkL0nVNunT6iHXIn1otvb1VbuRnaWL+WhnPXPbSRd rU9d7zzQTPoiHcc6O10i0LuGhqQqDD2CDCLou32M/csAAAAAAAA= --------------ms020601040508070808010301-- --===============1350698984== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============1350698984==-- From sidr-bounces@ietf.org Mon Mar 17 17:29:50 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 969963A6CB2; Mon, 17 Mar 2008 17:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.452 X-Spam-Level: X-Spam-Status: No, score=-100.452 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMtjGbznttzN; Mon, 17 Mar 2008 17:29:49 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C79083A6C89; Mon, 17 Mar 2008 17:29:49 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 695913A6C89 for ; Mon, 17 Mar 2008 17:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sH+XzNw6cRD for ; Mon, 17 Mar 2008 17:29:48 -0700 (PDT) Received: from aep-us-dc-01.aep-net.com (unknown [63.139.155.212]) by core3.amsl.com (Postfix) with ESMTP id 85B3B3A6809 for ; Mon, 17 Mar 2008 17:29:48 -0700 (PDT) Received: from [172.16.50.201] ([76.110.31.20]) by aep-us-dc-01.aep-net.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Mar 2008 20:27:31 -0400 Message-Id: From: "Michele (Mike) Hjorleifsson" To: Robert Loomans In-Reply-To: <47DF04FB.9020103@apnic.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 17 Mar 2008 20:27:30 -0400 References: <4D22EF37-FCF2-48BB-889F-8FE8C17A1B04@aepnetworks.com> <47DE5161.3030104@ripe.net> <004201c88855$c77f8540$6e00a8c0@ad.redback.com> <47DF04FB.9020103@apnic.net> X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 18 Mar 2008 00:27:31.0458 (UTC) FILETIME=[DA9DFE20:01C8888E] Cc: sidr@ietf.org Subject: Re: [Sidr] Rsync X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Ok let me be a lil more clear, i wasnt referring to public access to the repo's i was talking about access to update the underlying information is the intent to allow the public to edit the data in these repositories, my concern would be that if unprotected (or writable) the repository could become compromised and the unsuspecting download a copy of corrupt data. On Mar 17, 2008, at 7:55 PM, Robert Loomans wrote: > Tony Li wrote: >> One benefit would be a secure, automatic exchanges without cleartext >> authentication. > > There is no authentication for the repositories. They are publicly, > anonymously available. > > Every party who wants to check one of your assertions (ROA, etc) > needs to be able to retrieve the appropriate certificates, CRLs, etc. > > Rob > > -- > Robert Loomans Email: robertl@apnic.net > Senior Software Engineer, APNIC Phone: +61 7 3858 > 3100 > http://www.apnic.net Fax: +61 7 3858 > 3199 _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Mar 17 17:56:49 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 552D528C25D; Mon, 17 Mar 2008 17:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.669 X-Spam-Level: X-Spam-Status: No, score=-100.669 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnMvXNor2byF; Mon, 17 Mar 2008 17:56:48 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7149228C135; Mon, 17 Mar 2008 17:56:48 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6E0728C141 for ; Mon, 17 Mar 2008 17:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8msq6zSLH9Jv for ; Mon, 17 Mar 2008 17:56:45 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 5AA393A6BA0 for ; Mon, 17 Mar 2008 17:56:45 -0700 (PDT) Received: from [202.12.29.217] (dhcp217.apnic.net [202.12.29.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 5FE76D5F2D; Tue, 18 Mar 2008 10:54:28 +1000 (EST) Message-ID: <47DF12C3.60705@apnic.net> Date: Tue, 18 Mar 2008 10:54:27 +1000 From: Robert Loomans Organization: APNIC - http://www.apnic.net/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: "Michele (Mike) Hjorleifsson" References: <4D22EF37-FCF2-48BB-889F-8FE8C17A1B04@aepnetworks.com> <47DE5161.3030104@ripe.net> <004201c88855$c77f8540$6e00a8c0@ad.redback.com> <47DF04FB.9020103@apnic.net> In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=C6B3AE7E; url=http://robert.loomans.org/0xC6B3AE7E.asc Cc: sidr@ietf.org Subject: Re: [Sidr] Rsync X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0885677827==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0885677827== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000502080001020904080306" This is a cryptographically signed message in MIME format. --------------ms000502080001020904080306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Michele (Mike) Hjorleifsson wrote: > Ok let me be a lil more clear, i wasnt referring to public access to the > repo's i was talking about access to update the underlying information > is the intent to allow the public to edit the data in these > repositories, my concern would be that if unprotected (or writable) the > repository could > become compromised and the unsuspecting download a copy of corrupt data. Ah... Updates to the repositories are an internal implementation decision between the CA, and the repository. None of the current drafts describe updating repositories. They only describe fetching from them. Rob -- Robert Loomans Email: robertl@apnic.net Senior Software Engineer, APNIC Phone: +61 7 3858 3100 http://www.apnic.net Fax: +61 7 3858 3199 --------------ms000502080001020904080306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCC BW8wggRXoAMCAQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UE ChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5h Z2VyQGFwbmljLm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNV BAYTAkFQMREwDwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTAL BgNVBAUTBDg5NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjF QP4OmyB73NE86ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs 02JKEd4Kwap6eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH 0PvpZNWiV3uBqhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR 7r2SJDQ8SXiUJy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+ uyZcsqAE7VVX0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAA MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklD IENsaWVudCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsG A1UdIwSBszCBsIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFV MQ4wDAYDVQQKEwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQD EyVBUE5JQyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkB FhNjYW1hbmFnZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0 MB4GA1UdEgQXMBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0 cHM6Ly93d3cuYXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0 dHBzOi8vd3d3LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZo dHRwczovL3d3dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOC AQEAhtnqJUiql+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq 32x4R8YHDgfUwq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiC gPx/wQ72Eyj6DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgk f2Qk5n8RiNEpzzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKT H3fAz9RQC3zprZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjCCBW8wggRXoAMC AQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMx GzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmlj Lm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNVBAYTAkFQMREw DwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTALBgNVBAUTBDg5 NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjFQP4OmyB73NE8 6ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs02JKEd4Kwap6 eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH0PvpZNWiV3uB qhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR7r2SJDQ8SXiU Jy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+uyZcsqAE7VVX 0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAAMBEGCWCGSAGG +EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklDIENsaWVudCBD ZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsGA1UdIwSBszCB sIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFVMQ4wDAYDVQQK EwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQDEyVBUE5JQyBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkBFhNjYW1hbmFn ZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0MB4GA1UdEgQX MBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0cHM6Ly93d3cu YXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0dHBzOi8vd3d3 LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwczovL3d3 dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAhtnqJUiq l+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq32x4R8YHDgfU wq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiCgPx/wQ72Eyj6 DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgkf2Qk5n8RiNEp zzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKTH3fAz9RQC3zp rZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjGCA8YwggPCAgEBMIGVMIGOMQsw CQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNl czEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAG CSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmljLm5ldAICIwMwCQYFKw4DAhoFAKCCAgUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwMzE4MDA1NDI3WjAj BgkqhkiG9w0BCQQxFgQUusHFvyPLfI0tQOHS/zSwlcQ+5tkwUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgaYGCSsGAQQBgjcQBDGBmDCBlTCBjjELMAkGA1UEBhMCQVUxDjAMBgNV BAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNVBAMTJUFQTklD IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0BCQEWE2NhbWFu YWdlckBhcG5pYy5uZXQCAiMDMIGoBgsqhkiG9w0BCRACCzGBmKCBlTCBjjELMAkGA1UEBhMC QVUxDjAMBgNVBAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNV BAMTJUFQTklDIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0B CQEWE2NhbWFuYWdlckBhcG5pYy5uZXQCAiMDMA0GCSqGSIb3DQEBAQUABIIBABf/Lx/ITaXp AcSnPPY09wKeooUACOUdmMKmoQNWiweCO5fy97i3jmqg5Rc2I9Hq2PqBEUYv+47l1OePDsgm +zCj3qWpAXJFxgVWHg5ImvzPQU57Rx+vy/ufIw56uPJwDDFOuYPdipoPwzDgiRjoSjm5Phrb 4xY94EgD4qUKMnxSOYJafrmqksAyEXVKhTGhF29jW5YiHbHWGUmrJ53Pr5w9QYd5rEVOLpMV nCRjTpWjsHJ5tc+yDct/L/T/9DPH0C326XJagBIdb4VhDLxG0sSGZQF/M22Md/x7Wm2xQ0/D zRkbi7WioHzDZYKYF6Syk8vRdhouQYnLMimxnfX/pfIAAAAAAAA= --------------ms000502080001020904080306-- --===============0885677827== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============0885677827==-- From sidr-bounces@ietf.org Mon Mar 17 18:10:16 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 213973A6814; Mon, 17 Mar 2008 18:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.653 X-Spam-Level: X-Spam-Status: No, score=-100.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arl6I7aQSCsd; Mon, 17 Mar 2008 18:10:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9489928C19A; Mon, 17 Mar 2008 18:10:14 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 662673A6814 for ; Mon, 17 Mar 2008 18:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1Nm-ols-b0k for ; Mon, 17 Mar 2008 18:10:08 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id F2D7D28C24E for ; Mon, 17 Mar 2008 18:10:07 -0700 (PDT) Received: from [202.12.29.217] (dhcp217.apnic.net [202.12.29.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 5C7E5D5F2D; Tue, 18 Mar 2008 11:07:50 +1000 (EST) Message-ID: <47DF15E5.8090906@apnic.net> Date: Tue, 18 Mar 2008 11:07:49 +1000 From: Robert Loomans Organization: APNIC - http://www.apnic.net/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Sandra Murphy References: In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=C6B3AE7E; url=http://robert.loomans.org/0xC6B3AE7E.asc Cc: sidr@ietf.org Subject: Re: [Sidr] rsync discussion history X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0626234284==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0626234284== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000802050102060306080707" This is a cryptographically signed message in MIME format. --------------ms000802050102060306080707 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable > You may recall a mention in Monday's meeting of license difficulties > for commercial implementations. >=20 > At this point in the history, I discovered that the rsync open source > project used a license that forbid charging for any code that > included their code. That would have made commercial implementations > problematic. [Disclaimer: INAL, etc.] Not quite. "Included" is the loaded word here. I haven't examined the GPL v3 in depth, but I have looked very carefully at v2. The GPL v2 tries to make the distinction between derived works (ie, modified versions of the licensed program) and "mere aggregation" for the purposes of distribution. Note: the GPL does not try to dictate what you do in the privacy of your own home/office. Typically this distinction is represented by looking at whether a program links to the GPL licensed code or not. If it does link to it, the linked code must be GPL for it to be distributed. In this case, if the rsync program is executed by proprietary software as a command line tool, and qualifies as "mere aggregation" then the only addition requirement on that software would be that it package the source to rsync along with the binary. > However, I just discovered that with the announcement of rsync 3.0 on > March 1, 2008 they have moved from GPL version 2 to GPL version 3:=20 > http://www.samba.org/rsync/GPL.html >=20 > From a first glance through, I can not find similar text that would=20 > prohibit charging for code that includes their code. People who are > used to reading these GPL licences should take a look to see if you > see limits on commercial use of the rsync code. >=20 > So the difficulty about commercial implementations could be OBE. GPL v3 appears to make a similar distinction=20 http://www.gnu.org/licenses/gpl.html section 5: > A compilation of a covered work with other separate and independent > works, which are not by their nature extensions of the covered work, > and which are not combined with it such as to form a larger program, > in or on a volume of a storage or distribution medium, is called an > =E2=80=9Caggregate=E2=80=9D if the compilation and its resulting copyr= ight are not > used to limit the access or legal rights of the compilation's users > beyond what the individual works permit. Inclusion of a covered work > in an aggregate does not cause this License to apply to the other > parts of the aggregate. Rob --=20 Robert Loomans Email: robertl@apnic.net Senior Software Engineer, APNIC Phone: +61 7 3858 3100 http://www.apnic.net Fax: +61 7 3858 3199 --------------ms000802050102060306080707 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCC BW8wggRXoAMCAQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UE ChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5h Z2VyQGFwbmljLm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNV BAYTAkFQMREwDwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTAL BgNVBAUTBDg5NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjF QP4OmyB73NE86ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs 02JKEd4Kwap6eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH 0PvpZNWiV3uBqhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR 7r2SJDQ8SXiUJy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+ uyZcsqAE7VVX0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAA MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklD IENsaWVudCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsG A1UdIwSBszCBsIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFV MQ4wDAYDVQQKEwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQD EyVBUE5JQyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkB FhNjYW1hbmFnZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0 MB4GA1UdEgQXMBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0 cHM6Ly93d3cuYXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0 dHBzOi8vd3d3LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZo dHRwczovL3d3dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOC AQEAhtnqJUiql+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq 32x4R8YHDgfUwq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiC gPx/wQ72Eyj6DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgk f2Qk5n8RiNEpzzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKT H3fAz9RQC3zprZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjCCBW8wggRXoAMC AQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMx GzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmlj Lm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNVBAYTAkFQMREw DwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTALBgNVBAUTBDg5 NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjFQP4OmyB73NE8 6ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs02JKEd4Kwap6 eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH0PvpZNWiV3uB qhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR7r2SJDQ8SXiU Jy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+uyZcsqAE7VVX 0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAAMBEGCWCGSAGG +EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklDIENsaWVudCBD ZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsGA1UdIwSBszCB sIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFVMQ4wDAYDVQQK EwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQDEyVBUE5JQyBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkBFhNjYW1hbmFn ZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0MB4GA1UdEgQX MBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0cHM6Ly93d3cu YXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0dHBzOi8vd3d3 LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwczovL3d3 dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAhtnqJUiq l+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq32x4R8YHDgfU wq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiCgPx/wQ72Eyj6 DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgkf2Qk5n8RiNEp zzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKTH3fAz9RQC3zp rZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjGCA8YwggPCAgEBMIGVMIGOMQsw CQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNl czEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAG CSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmljLm5ldAICIwMwCQYFKw4DAhoFAKCCAgUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwMzE4MDEwNzQ5WjAj BgkqhkiG9w0BCQQxFgQUZVUoRnRH95l8JPEoC4kri3YfwoMwUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgaYGCSsGAQQBgjcQBDGBmDCBlTCBjjELMAkGA1UEBhMCQVUxDjAMBgNV BAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNVBAMTJUFQTklD IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0BCQEWE2NhbWFu YWdlckBhcG5pYy5uZXQCAiMDMIGoBgsqhkiG9w0BCRACCzGBmKCBlTCBjjELMAkGA1UEBhMC QVUxDjAMBgNVBAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNV BAMTJUFQTklDIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0B CQEWE2NhbWFuYWdlckBhcG5pYy5uZXQCAiMDMA0GCSqGSIb3DQEBAQUABIIBANqmMAKOAZwW 4NfvFKkyRIrzGOhCG8EHiqTQJLcxhpr3VsQ4MSnkVxV6SWABdbUynw+hp5RUUvuPYUSNLPoG OJdjNniXvFGUD8XVuNB/KAM0dWJFES7ITwJ3j09KnHNS816mzoNcoEzGoqu9kGXWdH55snz2 zZzFH0rJEbZczKve05Xq0l+XC6Xmc4juS1ejE0CXCHuoViF7OkQ3XyErm8V1hTNVViN8QQtZ OyYxY9AlbJGcLTLXHSmi20QfLpNy4Mk9niagO4fL7i93pEvQUXhrqbdSoaiONYLxj2bPrh6L 7BJEnPlnmGjhd2lkT3rk1rJDs/OxmdyHPzYcbDXh51cAAAAAAAA= --------------ms000802050102060306080707-- --===============0626234284== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============0626234284==-- From sidr-bounces@ietf.org Mon Mar 17 19:55:00 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1C2E3A6EB5; Mon, 17 Mar 2008 19:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.434 X-Spam-Level: X-Spam-Status: No, score=-99.434 tagged_above=-999 required=5 tests=[AWL=-1.064, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGXZr0FX1rB4; Mon, 17 Mar 2008 19:55:00 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246C93A6E9B; Mon, 17 Mar 2008 19:55:00 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84B983A6E9C for ; Mon, 17 Mar 2008 19:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyEi7SKzFhh7 for ; Mon, 17 Mar 2008 19:54:57 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id C90363A6942 for ; Mon, 17 Mar 2008 19:54:57 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 65258268037; Mon, 17 Mar 2008 20:52:41 -0600 (MDT) Received: from 206.83.83.11.ptr.us.xo.net (bedford.lex.arbor.net [204.118.128.2]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Mon, 17 Mar 2008 20:52:41 -0600 (MDT) (envelope-from danny@tcb.net) Message-Id: From: Danny McPherson To: Matt Lepinski In-Reply-To: <478F6BFA.8090301@bbn.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 17 Mar 2008 20:52:24 -0600 References: <478F6BFA.8090301@bbn.com> X-Mailer: Apple Mail (2.919.2) Cc: sidr@ietf.org Subject: Re: [Sidr] Multiple Signatures on a ROA: Proposal X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Jan 17, 2008, at 7:53 AM, Matt Lepinski wrote: > At IETF 70, Geoff and I agreed to put together a concrete proposal > for how multiple signatures on a ROA would work. Matt et al., Upon thinking about this more, I'm now wondering why this would be needed beyond one example. That example is where multiple CAs 'own' the prefixes that are being aggregated and therefore a single CA certificate for the aggregate cannot be obtained. Does anyone have other examples of where this would arise? I still stand by by statement that SIDR should NOT impose any constraints that do not exist in the routing system, but I'm wondering how likely the probability of the above is, or if there are other cases where this may occur. -danny _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Mar 17 20:01:53 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EEB43A6EC5; Mon, 17 Mar 2008 20:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.707 X-Spam-Level: X-Spam-Status: No, score=-100.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4T4Nt3R0TV3; Mon, 17 Mar 2008 20:01:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A0423A6E7E; Mon, 17 Mar 2008 20:01:52 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD2EC3A6E7E for ; Mon, 17 Mar 2008 20:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfdHpyHDhZC7 for ; Mon, 17 Mar 2008 20:01:50 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id BA6083A6E3A for ; Mon, 17 Mar 2008 20:01:50 -0700 (PDT) Received: from dhcp6.potaroo.net (dhcp6.potaroo.net [203.10.60.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 53D0BD5F2D; Tue, 18 Mar 2008 12:59:33 +1000 (EST) Message-ID: <47DF3014.5030801@apnic.net> Date: Tue, 18 Mar 2008 13:59:32 +1100 From: Geoff Huston User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Robert Loomans References: <4D22EF37-FCF2-48BB-889F-8FE8C17A1B04@aepnetworks.com> <47DE5161.3030104@ripe.net> <004201c88855$c77f8540$6e00a8c0@ad.redback.com> <47DF04FB.9020103@apnic.net> <47DF12C3.60705@apnic.net> In-Reply-To: <47DF12C3.60705@apnic.net> Cc: "Michele \(Mike\) Hjorleifsson" , sidr@ietf.org Subject: Re: [Sidr] Rsync X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Robert Loomans wrote: > Michele (Mike) Hjorleifsson wrote: >> Ok let me be a lil more clear, i wasnt referring to public access to >> the repo's i was talking about access to update the underlying >> information >> is the intent to allow the public to edit the data in these >> repositories, my concern would be that if unprotected (or writable) >> the repository could >> become compromised and the unsuspecting download a copy of corrupt data. > > Ah... Updates to the repositories are an internal implementation > decision between the CA, and the repository. None of the current drafts > describe updating repositories. They only describe fetching from them. Actually draft-huston-sidr-repos-structure attempted to do precisely that Section 2 of that document may be a but implicit, but it defines as instance of a publication repository as containing all the signed products of a CA or the signed products of an EE. What is implicit is that neither a CA nor an EE would allow third parties to write to their publication repository. Also note that as these are all signed, foreign objects are detectable by relying parties. Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Mar 17 20:08:23 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6103A68EC; Mon, 17 Mar 2008 20:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.301 X-Spam-Level: X-Spam-Status: No, score=-99.301 tagged_above=-999 required=5 tests=[AWL=-0.931, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRR+YMIKDZhb; Mon, 17 Mar 2008 20:08:19 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBFE23A6900; Mon, 17 Mar 2008 20:08:18 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875043A6932 for ; Mon, 17 Mar 2008 20:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1KO+2g5cLwt for ; Mon, 17 Mar 2008 20:08:15 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 7591C3A6CBF for ; Mon, 17 Mar 2008 20:08:01 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 0F922268037; Mon, 17 Mar 2008 21:05:45 -0600 (MDT) Received: from 206.83.83.11.ptr.us.xo.net (bedford.lex.arbor.net [204.118.128.2]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Mon, 17 Mar 2008 21:05:44 -0600 (MDT) (envelope-from danny@tcb.net) Message-Id: <8EA7888C-5E33-4223-B71B-A5EC7F3E8A9B@tcb.net> From: Danny McPherson To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 17 Mar 2008 21:05:27 -0600 X-Mailer: Apple Mail (2.919.2) Subject: [Sidr] On Time and Frequency of ROA Publication X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org In reading draft-ietf-sidr-cp-03, and S 2.3 specifically, I have a couple questions: "A new ROA will be published before a predecessor ROA has expired, or within 24 hours after an address space holder has changed the set of ASes that is authorized to advertise the address blocks it holds." What do folks believe would be normal behavior in a system if the CA and a new ROA were not available for some extended period of time? For example, some natural disaster occurred? I know an individual RP could "opt out", but that's not realistic for Internet-wide deployment. Second, if a new ROA is required and that information is employed directly by the routing system and validated by a protocol such as SBGP, would this model require that each routing entry for which a ROA exists be readvertised every ~24 hours? I understand how an offline system could suppress certificate updates, but not if this information is directly employed by the routing system itself. Thanks! -danny _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Mar 17 20:09:36 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9CB43A6C5F; Mon, 17 Mar 2008 20:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.746 X-Spam-Level: X-Spam-Status: No, score=-100.746 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jA+JM6BHDqnQ; Mon, 17 Mar 2008 20:09:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45C0C3A6900; Mon, 17 Mar 2008 20:09:35 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 641843A6900 for ; Mon, 17 Mar 2008 20:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbYP3IIo1EL8 for ; Mon, 17 Mar 2008 20:09:30 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 644E33A6822 for ; Mon, 17 Mar 2008 20:09:30 -0700 (PDT) Received: from dhcp6.potaroo.net (dhcp6.potaroo.net [203.10.60.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 312E6D5F2D; Tue, 18 Mar 2008 13:07:13 +1000 (EST) Message-ID: <47DF31E0.6000002@apnic.net> Date: Tue, 18 Mar 2008 14:07:12 +1100 From: Geoff Huston User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Danny McPherson References: <478F6BFA.8090301@bbn.com> In-Reply-To: Cc: sidr@ietf.org Subject: Re: [Sidr] Multiple Signatures on a ROA: Proposal X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Danny McPherson wrote: > On Jan 17, 2008, at 7:53 AM, Matt Lepinski wrote: > >> At IETF 70, Geoff and I agreed to put together a concrete proposal >> for how multiple signatures on a ROA would work. > > Matt et al., > Upon thinking about this more, I'm now wondering why > this would be needed beyond one example. That example > is where multiple CAs 'own' the prefixes that are being > aggregated and therefore a single CA certificate for the > aggregate cannot be obtained. > > Does anyone have other examples of where this would > arise? Here's a hypothetical example: An academic and research network with academic instituations as members is the exclusive upstream provider for these institutions. The member institutions are all holders of legacy space, and the a & r network would like to do the right thing bgp-routing aggregation-wise and announce the maximallu spanning aggregation across all these elements. But even when there are adjacent address blocks the signatories are distinct entities, and the A & R network would need to get the ROA for the aggregate signed by both (or as many as could be aggregated into a single advertisement) in order to generate a ROA for the aggregate. > I still stand by by statement that SIDR should NOT > impose any constraints that do not exist in the routing > system, but I'm wondering how likely the probability of > the above is, or if there are other cases where this > may occur. Someone would need to troll through the BGP table dumps to find out how often this occurs in practice. Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Mar 17 20:20:44 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53FC13A6EA4; Mon, 17 Mar 2008 20:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.653 X-Spam-Level: X-Spam-Status: No, score=-100.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDcIJz8HzQjX; Mon, 17 Mar 2008 20:20:43 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75F8A3A68EC; Mon, 17 Mar 2008 20:20:43 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7337C3A6DEA for ; Mon, 17 Mar 2008 20:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzau17CEYdgT for ; Mon, 17 Mar 2008 20:20:40 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 289E63A6C5F for ; Mon, 17 Mar 2008 20:20:40 -0700 (PDT) Received: from [202.12.29.217] (dhcp217.apnic.net [202.12.29.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 1A4BAD5F2D; Tue, 18 Mar 2008 13:18:23 +1000 (EST) Message-ID: <47DF347E.3090102@apnic.net> Date: Tue, 18 Mar 2008 13:18:22 +1000 From: Robert Loomans Organization: APNIC - http://www.apnic.net/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Geoff Huston References: <4D22EF37-FCF2-48BB-889F-8FE8C17A1B04@aepnetworks.com> <47DE5161.3030104@ripe.net> <004201c88855$c77f8540$6e00a8c0@ad.redback.com> <47DF04FB.9020103@apnic.net> <47DF12C3.60705@apnic.net> <47DF3014.5030801@apnic.net> In-Reply-To: <47DF3014.5030801@apnic.net> X-Enigmail-Version: 0.95.6 OpenPGP: id=C6B3AE7E; url=http://robert.loomans.org/0xC6B3AE7E.asc Cc: "Michele \(Mike\) Hjorleifsson" , sidr@ietf.org Subject: Re: [Sidr] Rsync X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1662477858==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1662477858== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010807090401070309030404" This is a cryptographically signed message in MIME format. --------------ms010807090401070309030404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> Ah... Updates to the repositories are an internal implementation >> decision between the CA, and the repository. None of the current >> drafts describe updating repositories. They only describe fetching >> from them. > > Actually draft-huston-sidr-repos-structure attempted to do precisely that > > Section 2 of that document may be a but implicit, but it defines as > instance of a publication repository as containing all the signed > products of a CA or the signed products of an EE. What is implicit is > that neither a CA nor an EE would allow third parties to write to their > publication repository. Also note that as these are all signed, foreign > objects are detectable by relying parties. Ok, what I said was poorly worded. I'll rephrase: None of the current drafts specify the mechanisms or protocols used to modify the contents of the repositories. Rob -- Robert Loomans Email: robertl@apnic.net Senior Software Engineer, APNIC Phone: +61 7 3858 3100 http://www.apnic.net Fax: +61 7 3858 3199 --------------ms010807090401070309030404 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCC BW8wggRXoAMCAQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UE ChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5h Z2VyQGFwbmljLm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNV BAYTAkFQMREwDwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTAL BgNVBAUTBDg5NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjF QP4OmyB73NE86ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs 02JKEd4Kwap6eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH 0PvpZNWiV3uBqhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR 7r2SJDQ8SXiUJy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+ uyZcsqAE7VVX0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAA MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklD IENsaWVudCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsG A1UdIwSBszCBsIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFV MQ4wDAYDVQQKEwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQD EyVBUE5JQyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkB FhNjYW1hbmFnZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0 MB4GA1UdEgQXMBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0 cHM6Ly93d3cuYXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0 dHBzOi8vd3d3LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZo dHRwczovL3d3dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOC AQEAhtnqJUiql+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq 32x4R8YHDgfUwq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiC gPx/wQ72Eyj6DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgk f2Qk5n8RiNEpzzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKT H3fAz9RQC3zprZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjCCBW8wggRXoAMC AQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMx GzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmlj Lm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNVBAYTAkFQMREw DwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTALBgNVBAUTBDg5 NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjFQP4OmyB73NE8 6ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs02JKEd4Kwap6 eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH0PvpZNWiV3uB qhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR7r2SJDQ8SXiU Jy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+uyZcsqAE7VVX 0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAAMBEGCWCGSAGG +EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklDIENsaWVudCBD ZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsGA1UdIwSBszCB sIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFVMQ4wDAYDVQQK EwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQDEyVBUE5JQyBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkBFhNjYW1hbmFn ZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0MB4GA1UdEgQX MBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0cHM6Ly93d3cu YXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0dHBzOi8vd3d3 LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwczovL3d3 dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAhtnqJUiq l+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq32x4R8YHDgfU wq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiCgPx/wQ72Eyj6 DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgkf2Qk5n8RiNEp zzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKTH3fAz9RQC3zp rZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjGCA8YwggPCAgEBMIGVMIGOMQsw CQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNl czEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAG CSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmljLm5ldAICIwMwCQYFKw4DAhoFAKCCAgUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwMzE4MDMxODIyWjAj BgkqhkiG9w0BCQQxFgQUf1YVSFsiovfy9AT2P1wMNLvUIgQwUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgaYGCSsGAQQBgjcQBDGBmDCBlTCBjjELMAkGA1UEBhMCQVUxDjAMBgNV BAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNVBAMTJUFQTklD IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0BCQEWE2NhbWFu YWdlckBhcG5pYy5uZXQCAiMDMIGoBgsqhkiG9w0BCRACCzGBmKCBlTCBjjELMAkGA1UEBhMC QVUxDjAMBgNVBAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNV BAMTJUFQTklDIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0B CQEWE2NhbWFuYWdlckBhcG5pYy5uZXQCAiMDMA0GCSqGSIb3DQEBAQUABIIBALm2VtBExJUD gN68ZyHZZnpX2iN91+2Dvvm1wd1NnCKyCK8t/G1iSfEEE5zjcsITamRLbW7ixOYaFNAR3H4T HhV1YRD51evIVwP6cQGKT0lriYzmGnVhBH1W5fLQ1ZF7ejr26cD7Kn8pqN2t/jcGHHYp+VXH m/sPXqKc/+Z5kM26ry1SP7wPbS2Qrjhbzx4C7iISfVIQ45ZVEmIj5w3jBcMpZOanPNx70wQS h/FCcbWnt4mUBq2CaWUl5Gn1OdzSUngiRksyM9iTYQgnSw2DBgf+DM/OHeXQpi1xKi6t8KcP SQV2FsFHnDzjY4IcLK9BYY4n34HkjAVRrCc6x12mAdcAAAAAAAA= --------------ms010807090401070309030404-- --===============1662477858== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============1662477858==-- From sidr-bounces@ietf.org Mon Mar 17 20:52:22 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A73EC3A6E4B; Mon, 17 Mar 2008 20:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.646 X-Spam-Level: X-Spam-Status: No, score=-100.646 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8VC+KL9-QEU; Mon, 17 Mar 2008 20:52:21 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4A253A6B16; Mon, 17 Mar 2008 20:52:21 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AB773A68CE for ; Mon, 17 Mar 2008 20:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6f8stCDo7lCG for ; Mon, 17 Mar 2008 20:52:20 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id C51D33A6B43 for ; Mon, 17 Mar 2008 20:52:19 -0700 (PDT) Received: from [202.12.29.217] (dhcp217.apnic.net [202.12.29.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id C8888D5F2D; Tue, 18 Mar 2008 13:50:02 +1000 (EST) Message-ID: <47DF3BEA.7010601@apnic.net> Date: Tue, 18 Mar 2008 13:50:02 +1000 From: Robert Loomans Organization: APNIC - http://www.apnic.net/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Jeffrey Haas References: <87lk4mih6x.fsf@mid.deneb.enyo.de> <20080314133803.GD29868@scc.mi.org> In-Reply-To: <20080314133803.GD29868@scc.mi.org> X-Enigmail-Version: 0.95.6 OpenPGP: id=C6B3AE7E; url=http://robert.loomans.org/0xC6B3AE7E.asc Cc: sidr@ietf.org Subject: Re: [Sidr] rsync discussion history X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1966224140==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1966224140== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010206050706080109000408" This is a cryptographically signed message in MIME format. --------------ms010206050706080109000408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jeffrey Haas wrote: > Florian, > > On Thu, Mar 13, 2008 at 07:59:02PM +0100, Florian Weimer wrote: >> It's not clear to me if you need rsync's capability for transmitting >> collections of files. It is needed. For the major use case, relying parties will need to get all published products of each CA, by walking the certificate hierarchy from the top down. In each case, the SIA extension of each certificate will point to a repository directory where the certificate's products are published. The relying party needs to retrieve all of those, and repeat... > This is the major advantage of using rsync. When you must sync a large > number of files, it is *very* efficient. What's more it's very efficient over high latency links, and it recovers gracefully if you have to restart because of connection failures, etc. > For our purposes, we just care that we can gather all of the necessary > files. This can be as simple as downloading the latest manifest and > then fetching all changed files within the manifest. This was one of > the reasons I had suggested a "last updated" value for the items in the > manifest at the microphone at the SIDR meeting. That's certainly possible.... assuming the manifest is there. Currently the manifests are optional. Rob -- Robert Loomans Email: robertl@apnic.net Senior Software Engineer, APNIC Phone: +61 7 3858 3100 http://www.apnic.net Fax: +61 7 3858 3199 --------------ms010206050706080109000408 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCC BW8wggRXoAMCAQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UE ChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5h Z2VyQGFwbmljLm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNV BAYTAkFQMREwDwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTAL BgNVBAUTBDg5NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjF QP4OmyB73NE86ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs 02JKEd4Kwap6eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH 0PvpZNWiV3uBqhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR 7r2SJDQ8SXiUJy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+ uyZcsqAE7VVX0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAA MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklD IENsaWVudCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsG A1UdIwSBszCBsIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFV MQ4wDAYDVQQKEwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQD EyVBUE5JQyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkB FhNjYW1hbmFnZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0 MB4GA1UdEgQXMBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0 cHM6Ly93d3cuYXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0 dHBzOi8vd3d3LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZo dHRwczovL3d3dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOC AQEAhtnqJUiql+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq 32x4R8YHDgfUwq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiC gPx/wQ72Eyj6DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgk f2Qk5n8RiNEpzzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKT H3fAz9RQC3zprZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjCCBW8wggRXoAMC AQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMx GzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmlj Lm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNVBAYTAkFQMREw DwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTALBgNVBAUTBDg5 NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjFQP4OmyB73NE8 6ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs02JKEd4Kwap6 eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH0PvpZNWiV3uB qhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR7r2SJDQ8SXiU Jy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+uyZcsqAE7VVX 0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAAMBEGCWCGSAGG +EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklDIENsaWVudCBD ZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsGA1UdIwSBszCB sIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFVMQ4wDAYDVQQK EwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQDEyVBUE5JQyBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkBFhNjYW1hbmFn ZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0MB4GA1UdEgQX MBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0cHM6Ly93d3cu YXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0dHBzOi8vd3d3 LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwczovL3d3 dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAhtnqJUiq l+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq32x4R8YHDgfU wq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiCgPx/wQ72Eyj6 DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgkf2Qk5n8RiNEp zzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKTH3fAz9RQC3zp rZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjGCA8YwggPCAgEBMIGVMIGOMQsw CQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNl czEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAG CSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmljLm5ldAICIwMwCQYFKw4DAhoFAKCCAgUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwMzE4MDM1MDAyWjAj BgkqhkiG9w0BCQQxFgQU6QyqX3vznuinsB1GTkfywUc3xl0wUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgaYGCSsGAQQBgjcQBDGBmDCBlTCBjjELMAkGA1UEBhMCQVUxDjAMBgNV BAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNVBAMTJUFQTklD IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0BCQEWE2NhbWFu YWdlckBhcG5pYy5uZXQCAiMDMIGoBgsqhkiG9w0BCRACCzGBmKCBlTCBjjELMAkGA1UEBhMC QVUxDjAMBgNVBAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNV BAMTJUFQTklDIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0B CQEWE2NhbWFuYWdlckBhcG5pYy5uZXQCAiMDMA0GCSqGSIb3DQEBAQUABIIBACe749bCGnZ+ BbTZLCdlHX7CIrr7f7wjSisb0PUrXw4vASgBtD8KW9EDu8cXopVlfm9BUBoNKdczckDBVsfJ lcJiBn9AzrfNmItLF+NCqNdn9uycHdJnaT79/b6zQja+0j+b3s+/rKhx1Z9tg/BT2PxzCKMB hOd3uDtwNw/cVSTFA6sXjc3hjQPMJtCifIiwFAR35pxgJmbxxK2Mq1f3nc7jc7Ef7pl5TyTK B06LSTA/Mdt4ZF8TIyhNeUw3CfJfEEi+ZkD2DTrjM/Q0ordLsThhfqsyY7ykWApqhsHpAKf8 FoMJ8e3TBiDhoUjH3CJjvB1sF1AQBW8girezPvocJPcAAAAAAAA= --------------ms010206050706080109000408-- --===============1966224140== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============1966224140==-- From sidr-bounces@ietf.org Mon Mar 17 21:23:44 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44BF63A6E3D; Mon, 17 Mar 2008 21:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.669 X-Spam-Level: X-Spam-Status: No, score=-100.669 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOUaJBZ8rzBQ; Mon, 17 Mar 2008 21:23:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D885E3A6BCA; Mon, 17 Mar 2008 21:23:42 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0005928C153 for ; Mon, 17 Mar 2008 21:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAN9f7sV+eY3 for ; Mon, 17 Mar 2008 21:23:40 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id A831D28C145 for ; Mon, 17 Mar 2008 21:23:38 -0700 (PDT) Received: from dhcp6.potaroo.net (dhcp6.potaroo.net [203.10.60.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 13ED5D5F2D for ; Tue, 18 Mar 2008 14:21:18 +1000 (EST) Message-ID: <47DF4337.2040102@apnic.net> Date: Tue, 18 Mar 2008 15:21:11 +1100 From: Geoff Huston User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: sidr@ietf.org References: <478F6BFA.8090301@bbn.com> In-Reply-To: Subject: [Sidr] Minutes of the SIDR WG meeting @ ietf 71 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Thanks to Russ Mundy for these minutes. Geoff & Sandy SIDR - IETF 71 Securing Inter-Domain Routing (SIDR) WG Meeting 10 Mar 2008, 1740 - 1950 CHAIRS: Geoff Huston &; Sandy Murphy NOTE TAKER: Russ Mundy AGENDA: 1. Administrivia Mailing list: http://www.ietf.org/mail-archive/web/sidr/index.html Blue Sheets Agenda Bashing 2. SIDR and Origin Validation - Geoff Huston 3. Certificate Policy and CPS drafts - Steve Kent Certificate Policy http://www.ietf.org/internet-drafts/draft-ietf-sidr-cp-03.txt CPS for ISPs http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-isp-02.txt CPS for Registries http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-irs-03.txt 4. RPKI Architecture Update - Matt Lepinski http://www.ietf.org/internet-drafts/draft-ietf-sidr-arch-03.txt 5. Route Originations - Matt Lepinski http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-format-02.txt 6. Repository Structure - George Michaelson http://www.ietf.org/internet-drafts/draft-huston-sidr-repos-struct-01.txt 7. ROA Validation - George Michaelson http://www.ietf.org/internet-drafts/draft-huston-sidr-roa-validation-00.txt 8. Bogon Origin Attestations - Geoff Huston http://www.ietf.org/internet-drafts/draft-huston-sidr-bogons-00.txt SUMMARY: The WG agenda items covered the overall approach being used by the WG to address the issues of origin validation and then examined a number of specific aspects of routing origination attestations in relation to a Resource PKI. Following a report to the WG from RPSEC on requirements for BGP routing security, it was noted that no clear guidance on the topic of AS Path validation was forthcoming. SIDR should undertake a solution for AS Path validation. The AD suggested that the charter revision should be done by IETF72. One general comment at the end of the meeting was that it would be useful to have a roadmap for the relationship and anticipated timing of completion of the various work items discussed during the meeting. The co-chairs acknowledged that this might be useful, but should be discussed further on the WG mailing list. NOTES: SIDR and Origin Validation Geoff Huston presented a status report on the SIDR Working Group activities relating to origination validation in inter-domain routing. The presentation provided a summary of the reason for creation of SIDR and set of requirements for the working group. The main focus of the working group is the specification of a PKI that supports validation of origination information contained in the routing system, and the manner in which validation tools could be incorporated into the routing architecture. Questions / Comments: There was no controversy related to the presentation but the AD asked where the information was described. Geoff acknowledged that he needed to write an RFC to document much of what he presented in his summary. During the presentation, there was also a discussion about the SIDR requirements and work being "locked to RPSEC". The general sense of the room was that this should be changed in the SIDR charter - no one in the room objected to this change. Part of this discussion of SIDR working group scope was taking on solving the problem of path validation. The sense of the room was that SIDR should undertake a solution for path validation. The AD suggested that the charter revision should be done by IETF 72. ACTIONS: - Chairs to propose a revised charter for the SIDR WG to address the topic of measures to support validation of the AS Path. - Draft to be proposed to the WG on the overall approach to Origination validation. Geoff Huston will work on this draft. Certificate Policy and CPS drafts Steve Kent presented on three CP and CPS drafts. The most significant changes since the previous WG meeting has been with the CPS template for RIRs. The majority of this work focused on enhancing the template so that less work will be needed on the part of RIRs using the templates. Steve has worked with APNIC in completing their CPS, which they were able to do in two days. One important aspect pointed during the presentation was that a business PKI that is separate from the resource PKI will be required. Questions / Comments: During the discussion from the floor, there was a suggestion that a complete template be created that could be used by ISPs. This was accepted as a good suggestion. Another comment was that it would be useful to have a template that says the ISP has no liability of any sort. RPKI Architecture Update Matt Lepinski presented on the RPKI architecture. The opening request is for everyone to read and comment on the draft. Matt considers the current text is to be inadequate in certain areas, and requests inputs with specific, new text. Questions / Comments: There was some discussion about changing the scope of this document so that it would align with the expected charter changes. The general sense of the room was to keep the current scope and focus on completing the document. The document probably needs some clarification regarding intended scope. Additionally, the document is intended to provide examples rather than explicit directions so some words need to be updated. ACTIONS: - Draft to be revised to clarify intended scope regarding the architecture of the RPKI and reference related documents concerning further details of the use of Manifests, ROAs, BOAs and the forms of potential use in supporting routing activities. Route Originations Matt Lepinski presented on the current ROA specification document and the current issue relating to whether to add the capability for multiple signatures into a ROA or not. A specification as to how multiple signatures could be included in the ROA was presented. Questions / Comments: There was a significant discussion about the ROA format and number of signatures on a ROA. There were generally two (opposing) views expressed there were largely the same as have been expressed on the mail list. The minute takers' general summary of the issue is: Supporters of multiple signatures: SIDR work should not constrain or restrict the way in which the routing system and resource assignments operate currently or in the future. Opponents of multiple signatures: This is an effort to solve a problem that is extremely small (or non-existent) which introduces significant complexity of the validation implementations (and possibly all validations). During the discussions, some new ideas such as specifying the use of multiple signatures on a ROA but defining that only one signature will be used initially on a ROA - a request was made for Jeffrey Hass write up this idea for the WG. There was also a suggestion that if multiple signatures were used, they should only be applied when multiple parties were involved. Geoff suggested that it might be useful to specify that validation of a ROA would not be done over any larger address space than contained in the ROA. A ROA cannot be used to validate any object that is larger than the span of the address in the ROA. The implication of this limitation is that if it is required to sign an aggregate address object where the components are drawn from distinct validation paths, then multiple signatures in the ROA would be necessary. ACTIONS: - Jeffrey Hass to describe an approach to multiple signatures on a ROA where the case of multiple signatures is defined, but note intended use to be constrained to single signatures. - Multiple signatures in a ROA to be taken to the WG mailing list. Repository Structure George Michaelson next presented on the Repository Structure draft. The draft has been pretty much rewritten since the -00 draft, in response to a batch of inputs. The slides provide a summary of the changes from the 00 version. The authors believe that the 01 version incorporates the comments they received to date. They would also like to have further review and comments on the draft. Questions / Comments: During this presentation, a member of the working group asked if this was the right time to discuss the issues around the use of rsync as defined in the specification. There have been discussions about this on the WG list but they have not been conclusive. After some discussion in the meeting, Sandy took an action to write a description and summary of the rsync related issues and send it to the WG list and AD. At this point, it sounds like the working group members in the room see the need to have specific agenda time to discuss these issues at the IETF72 SIDR WG meeting. ACTIONS: - Sandy Murphy to write a description of the issues in the use of RSYNC in the RPKI specification, and circulate this to the AD and the WG. ROA Validation George Michaelson presented on ROA Validation. The list of issues in the last slide of the presentation may not be complete but are likely the ones that need to be worked on first - comments are solicited. Questions / Comments: Some of the substantive comments that were raised from WG members in the room related to operational timeliness and the amount of time needed to effect changes to signed originations, e.g., an ISP moves all traffic from one link to another (changing origination point and issuing a new ROA) but their traffic is not being delivered everywhere since some places are validating on the old ROA - a 24 hour cycle to get the new information in place is not operationally acceptable. Geoff & Steve both pointed out that relying parties can update information more frequently than 24 hours but there is no way to force people to update information on any particular period of time. The generic response to this was to pre-provision the necessary security credentials in the RPKI in advance of the use of a particular origination arrangement in the routing system. There was also discussion about approaches that were needed during the transition period of particular adoption, when ROAs are being issued for some but not all originations. Some ideas are included in the draft and summarized in the slides. The working group was asked to think about transition and contribute additional ideas. Bogon Origin Attestations Geoff Huston presented on Bogon Origin Attestations. The concept motivating the BOA idea is to provide a mechanism for legitimate holders of resources to make an authenticatable statement the certain resources should not be appearing in the routing system. In general, BOAs are modelled after ROAs but if a relying party encounters both a ROA and a BOA for a given space, the ROA will always override a BOA. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 18 07:49:40 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD2B83A6F0E; Tue, 18 Mar 2008 07:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.518 X-Spam-Level: X-Spam-Status: No, score=-101.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZRKqE7M5OyV; Tue, 18 Mar 2008 07:49:40 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FD0D3A6F03; Tue, 18 Mar 2008 07:49:40 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BE493A68C9 for ; Tue, 18 Mar 2008 07:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FObnjAbkbIGE for ; Tue, 18 Mar 2008 07:49:34 -0700 (PDT) Received: from manos.scc.mi.org (manos.scc.mi.org [204.11.140.250]) by core3.amsl.com (Postfix) with ESMTP id EA12C3A6F03 for ; Tue, 18 Mar 2008 07:49:33 -0700 (PDT) Received: by manos.scc.mi.org (Postfix, from userid 1025) id D24AD4E4C4; Tue, 18 Mar 2008 10:47:16 -0400 (EDT) Date: Tue, 18 Mar 2008 10:47:16 -0400 From: Jeffrey Haas To: Terry Manderson Message-ID: <20080318144716.GA21684@scc.mi.org> References: <87lk4mih6x.fsf@mid.deneb.enyo.de> <20080314133803.GD29868@scc.mi.org> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: sidr@ietf.org Subject: Re: [Sidr] rsync discussion history X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Terry, On Sat, Mar 15, 2008 at 06:13:32AM +1000, Terry Manderson wrote: > I'm not going to go back through the process of discussing the merits > and downfalls of RSYNC or any other competing protocol or service that > might be used as the fetch mechanism. And this was not my original point. I said: > > For our purposes, we just care that we can gather all of the necessary > > files. This can be as simple as downloading the latest manifest and > > then fetching all changed files within the manifest. This was one of > > the reasons I had suggested a "last updated" value for the items in > > the > > manifest at the microphone at the SIDR meeting. The presence of a last updated field in the manifest means that you don't require remote file system last-time-touched state to determine what files you may need to fetch. rsync handles those details beautifully. In the absence of rsync, you need additional information to do this efficiently. -- Jeff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 18 09:03:02 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27EBC28C604; Tue, 18 Mar 2008 09:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.653 X-Spam-Level: X-Spam-Status: No, score=-100.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuDVH0NrHeMJ; Tue, 18 Mar 2008 09:02:56 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34D8628C60F; Tue, 18 Mar 2008 09:02:56 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B5A3A63EC for ; Tue, 18 Mar 2008 09:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i55pG1FuNNzG for ; Tue, 18 Mar 2008 09:02:50 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id AA75128C543 for ; Tue, 18 Mar 2008 09:02:48 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JbeEk-0000d8-4w; Tue, 18 Mar 2008 12:00:26 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <47DF04FB.9020103@apnic.net> References: <4D22EF37-FCF2-48BB-889F-8FE8C1 7A1B04@aepnetworks.com> <47DE5161.3030104@ripe.net> <004201c88855$c77f8540$6e00a8c0@ad.redback.com> <47DF04FB.9020103@apnic.net> Date: Tue, 18 Mar 2008 11:34:42 -0400 To: Robert Loomans From: Stephen Kent Cc: "'Michele \(Mike\) Hjorleifsson'" , sidr@ietf.org Subject: Re: [Sidr] Rsync X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 9:55 AM +1000 3/18/08, Robert Loomans wrote: >Content-Type: multipart/signed; >protocol="application/x-pkcs7-signature"; micalg=sha1; >boundary="------------ms040001000803000508020806" > >Tony Li wrote: >>One benefit would be a secure, automatic exchanges without cleartext >>authentication. > >There is no authentication for the repositories. They are publicly, >anonymously available. > >Every party who wants to check one of your assertions (ROA, etc) >needs to be able to retrieve the appropriate certificates, CRLs, etc. > >Rob > Rob, It has been suggested that access to repositories might be TLS-protected, even though the data is intended to be widely available. The motivation is that requiring a TLS credential (issued under the RPKI) could be used to reject DoS attacks by complete outsiders. Of course, one has to pay close attention to the implementation details to ensure that use of TLS does not itself become a vector for a DoS attack. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 18 09:47:36 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB96B28C694; Tue, 18 Mar 2008 09:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.653 X-Spam-Level: X-Spam-Status: No, score=-100.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKsWO5N8EoEh; Tue, 18 Mar 2008 09:47:23 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA6F928C65F; Tue, 18 Mar 2008 09:47:23 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB9383A68FC for ; Tue, 18 Mar 2008 09:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iV-ORc9Py5aQ for ; Tue, 18 Mar 2008 09:47:10 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 564613A69AB for ; Tue, 18 Mar 2008 09:47:01 -0700 (PDT) Received: from host-252-217.arin.net (dhcp182.apnic.net [202.12.29.182]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 4CCDDD5F2D for ; Wed, 19 Mar 2008 02:44:42 +1000 (EST) Message-Id: <69F836EC-0472-49DD-B155-341A7C6B23CC@apnic.net> From: Terry Manderson To: sidr@ietf.org In-Reply-To: <20080318144716.GA21684@scc.mi.org> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 19 Mar 2008 02:44:39 +1000 References: <87lk4mih6x.fsf@mid.deneb.enyo.de> <20080314133803.GD29868@scc.mi.org> <20080318144716.GA21684@scc.mi.org> X-Mailer: Apple Mail (2.919.2) Subject: Re: [Sidr] rsync discussion history X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi Jeff, On 19/03/2008, at 12:47 AM, Jeffrey Haas wrote: > Terry, > > On Sat, Mar 15, 2008 at 06:13:32AM +1000, Terry Manderson wrote: >> I'm not going to go back through the process of discussing the merits >> and downfalls of RSYNC or any other competing protocol or service >> that >> might be used as the fetch mechanism. > > And this was not my original point. I said: > I top posted my reply as I wasn't actually picking on you or challenging your point, I felt it worthwhile simply to highlight that there are options at that junction of the thread, so in some way we can have our cake and eat it too. :-) >>> For our purposes, we just care that we can gather all of the >>> necessary >>> files. This can be as simple as downloading the latest manifest and >>> then fetching all changed files within the manifest. This was one >>> of >>> the reasons I had suggested a "last updated" value for the items in >>> the >>> manifest at the microphone at the SIDR meeting. > > The presence of a last updated field in the manifest means that you > don't require remote file system last-time-touched state to > determine what > files you may need to fetch. rsync handles those details beautifully. > In the absence of rsync, you need additional information to do this > efficiently. I don't disagree there.. Terry -- Terry Manderson email: terry@apnic.net Network Operations Manager, APNIC sip: info@voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 18 10:28:21 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C98C28C63B; Tue, 18 Mar 2008 10:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.653 X-Spam-Level: X-Spam-Status: No, score=-100.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0E+ntHb3k2e; Tue, 18 Mar 2008 10:28:17 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A253A6CB3; Tue, 18 Mar 2008 10:28:17 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6648F3A69AB for ; Tue, 18 Mar 2008 10:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ii2THy2UMRZ8 for ; Tue, 18 Mar 2008 10:28:15 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 459643A6800 for ; Tue, 18 Mar 2008 10:28:15 -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 m2IHPI7V021847; Tue, 18 Mar 2008 12:25:18 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m2IHPG52030818; Tue, 18 Mar 2008 12:25:16 -0500 Received: from localhost ([157.185.81.151]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Mar 2008 13:25:15 -0400 Date: Tue, 18 Mar 2008 13:25:15 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Stephen Kent In-Reply-To: Message-ID: References: <4D22EF37-FCF2-48BB-889F-8FE8C1 7A1B04@aepnetworks.com> <47DE5161.3030104@ripe.net> <004201c88855$c77f8540$6e00a8c0@ad.redback.com> <47DF04FB.9020103@apnic.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 18 Mar 2008 17:25:15.0712 (UTC) FILETIME=[07BFB400:01C8891D] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Tue, 18 Mar 2008 12:25:18 -0500 (CDT) Cc: "'Michele \(Mike\) Hjorleifsson'" , sidr@ietf.org Subject: Re: [Sidr] Rsync X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, 18 Mar 2008, Stephen Kent wrote: > At 9:55 AM +1000 3/18/08, Robert Loomans wrote: > > It has been suggested that access to repositories might be > TLS-protected, even though the data is intended to be widely > available. The motivation is that requiring a TLS credential (issued > under the RPKI) could be used to reject DoS attacks by complete > outsiders. Can you say more about the TLS credential issued under the RPKI? First - so the credential would point in some way to the resource held as the source of the access? Second - are you suggesting that a repository would not be open to those who were not resource holders? (Like: academics looking for allocation patterns for research purposees would be just as denied as the trolls looking for allocation patters for commercial purposes?) Third - do commercial entities running global repositories as a service have a way to get such a TLS credential? What is it that I am missing? --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 18 10:51:05 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 621D128C646; Tue, 18 Mar 2008 10:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.363 X-Spam-Level: X-Spam-Status: No, score=-100.363 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGf8BWj+-Feh; Tue, 18 Mar 2008 10:50:59 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43D23A6B55; Tue, 18 Mar 2008 10:50:59 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BF363A6849 for ; Tue, 18 Mar 2008 10:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9USGd7k1gepV for ; Tue, 18 Mar 2008 10:50:55 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 811D428C26B for ; Tue, 18 Mar 2008 10:50:54 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id C0AA326803D; Tue, 18 Mar 2008 11:48:37 -0600 (MDT) Received: from [10.0.9.134] (bedford.lex.arbor.net [204.118.128.2]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Tue, 18 Mar 2008 11:48:37 -0600 (MDT) (envelope-from danny@tcb.net) Message-Id: From: Danny McPherson To: sidr@ietf.org In-Reply-To: <8EA7888C-5E33-4223-B71B-A5EC7F3E8A9B@tcb.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 18 Mar 2008 11:48:21 -0600 References: <8EA7888C-5E33-4223-B71B-A5EC7F3E8A9B@tcb.net> X-Mailer: Apple Mail (2.919.2) Subject: Re: [Sidr] On Time and Frequency of ROA Publication X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org OK, let me clarify my questions... Is there any guidance regarding how long a ROA should be valid? Geoff's BOA draft suggests that new BOA's should be issued on a 24 hour basis. The reason I ask is because if these are employed directly be a secure routing protocol then the amount of churn in the routing system as a result of periodic refreshes could be considerable (think RIPv1 - e.g., 250k/24/60/60 = ~3 updates per second, and that's being gratuitous). If they're cached out of band or employed to seed IRR objects the refreshes alone can be suppressed. Also, regarding this text in S 2.3 of sidr-cp-03: A new ROA will be published before a predecessor ROA has expired, or within 24 hours after an address space holder has changed the set of ASes that is authorized to advertise the address blocks it holds. So here, this would require that the holder of the address space pre-notify and provide a precise window for cutover from one origin AS to another. In this case, if it's actually the same entity but they're migrating AS numbers or the like, would they simply certify a ROA themselves for the other origin AS until the transition occurs? This is the most common case I can think of today where issues such as this may arise. And my question regarding availability of the CAs still stands, although I do realize its a very operational one, I think it's one we need to consider, and the Time and Frequency of Publication issues above have an impact on this. I'd particularly be interested in hearing about how the RIR folks are planning to deal with this. -danny On Mar 17, 2008, at 9:05 PM, Danny McPherson wrote: > In reading draft-ietf-sidr-cp-03, and S 2.3 specifically, I have > a couple questions: > "A new ROA will be published before a predecessor ROA has expired, or > within 24 hours after an address space holder has changed the set of > ASes that is authorized to advertise the address blocks it holds." > What do folks believe would be normal behavior in a system if > the CA and a new ROA were not available for some extended > period of time? For example, some natural disaster occurred? > I know an individual RP could "opt out", but that's not realistic for > Internet-wide deployment. > > Second, if a new ROA is required and that information is employed > directly by the routing system and validated by a protocol such as > SBGP, would this model require that each routing entry for which > a ROA exists be readvertised every ~24 hours? I understand how > an offline system could suppress certificate updates, but not if this > information is directly employed by the routing system itself. > > 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 sidr-bounces@ietf.org Tue Mar 18 11:53:31 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A93528C751; Tue, 18 Mar 2008 11:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.207 X-Spam-Level: X-Spam-Status: No, score=-101.207 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQrZ3u5JSXqz; Tue, 18 Mar 2008 11:53:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDB0728C706; Tue, 18 Mar 2008 11:53:15 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E42128C68F for ; Tue, 18 Mar 2008 11:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3T5kFujY5LHw for ; Tue, 18 Mar 2008 11:53:08 -0700 (PDT) Received: from nutshell.tislabs.com (nutshell.tislabs.com [192.94.214.100]) by core3.amsl.com (Postfix) with ESMTP id A507328C723 for ; Tue, 18 Mar 2008 11:52:19 -0700 (PDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id m2IIjvmF006266; Tue, 18 Mar 2008 13:45:58 -0500 (EST) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAszaq3l; Tue, 18 Mar 08 13:43:31 -0500 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 09A2F3F47F; Tue, 18 Mar 2008 14:41:47 -0400 (EDT) To: danny@tcb.net, sidr@ietf.org In-Reply-To: <8EA7888C-5E33-4223-B71B-A5EC7F3E8A9B@tcb.net> Message-Id: <20080318184147.09A2F3F47F@pecan.tislabs.com> Date: Tue, 18 Mar 2008 14:41:47 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) Cc: sandy@tislabs.com Subject: Re: [Sidr] On Time and Frequency of ROA Publication X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org >Second, if a new ROA is required and that information is employed >directly by the routing system and validated by a protocol such as >SBGP, would this model require that each routing entry for which >a ROA exists be readvertised every ~24 hours? I don't see why a new ROA would necessitate a new BGP Update. Can you say why that would be necessary? The Update should still be in the Adj-RIB-In, and the new ROA (absent changes in authorization, of course) should authorize it as well as the old ROA. --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 18 11:59:56 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0F83A6EF9; Tue, 18 Mar 2008 11:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.42 X-Spam-Level: X-Spam-Status: No, score=-100.42 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isKtQD8vfDQN; Tue, 18 Mar 2008 11:59:55 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BC5A3A6A65; Tue, 18 Mar 2008 11:59:55 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 325BF3A68B4 for ; Tue, 18 Mar 2008 11:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdGilkaQ8iE8 for ; Tue, 18 Mar 2008 11:59:53 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 6B1BB3A682A for ; Tue, 18 Mar 2008 11:59:53 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id CC66426803D; Tue, 18 Mar 2008 12:57:36 -0600 (MDT) Received: from [10.0.9.134] (bedford.lex.arbor.net [204.118.128.2]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 18 Mar 2008 12:57:36 -0600 (MDT) (envelope-from danny@tcb.net) Message-Id: <00F63B85-7653-44B8-95DD-C45C4576EF5D@tcb.net> From: Danny McPherson To: Sandy Murphy In-Reply-To: <20080318184147.09A2F3F47F@pecan.tislabs.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 18 Mar 2008 12:57:21 -0600 References: <20080318184147.09A2F3F47F@pecan.tislabs.com> X-Mailer: Apple Mail (2.919.2) Cc: sidr@ietf.org Subject: Re: [Sidr] On Time and Frequency of ROA Publication X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Mar 18, 2008, at 12:41 PM, Sandy Murphy wrote: >> Second, if a new ROA is required and that information is employed >> directly by the routing system and validated by a protocol such as >> SBGP, would this model require that each routing entry for which >> a ROA exists be readvertised every ~24 hours? > > I don't see why a new ROA would necessitate a new BGP Update. > > Can you say why that would be necessary? > > The Update should still be in the Adj-RIB-In, and the new ROA (absent > changes in authorization, of course) should authorize it as well > as the old ROA. Ahh, that's perhaps where I'm missing something. So, intermediate systems validate based on the ROA and it has a periodic expire with the associated certificate, doesn't the refreshed certificate need to be propagated each time it's refreshed - if employing such a capability in an inter-domain routing protocol? -danny _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 18 12:23:21 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022803A6F44; Tue, 18 Mar 2008 12:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.746 X-Spam-Level: X-Spam-Status: No, score=-100.746 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LM3L30aHngeF; Tue, 18 Mar 2008 12:23:20 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 181913A6AFD; Tue, 18 Mar 2008 12:23:20 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62B6F3A6A0F for ; Tue, 18 Mar 2008 12:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3A3hxtGX6NkJ for ; Tue, 18 Mar 2008 12:23:13 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 4FEB23A6B0E for ; Tue, 18 Mar 2008 12:23:12 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m2IJKsif028013; Tue, 18 Mar 2008 14:20:54 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m2IJKt4Y006992; Tue, 18 Mar 2008 14:20:55 -0500 Received: from localhost ([157.185.81.151]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Mar 2008 15:20:54 -0400 Date: Tue, 18 Mar 2008 15:20:53 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Danny McPherson In-Reply-To: <00F63B85-7653-44B8-95DD-C45C4576EF5D@tcb.net> Message-ID: References: <20080318184147.09A2F3F47F@pecan.tislabs.com> <00F63B85-7653-44B8-95DD-C45C4576EF5D@tcb.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 18 Mar 2008 19:20:54.0742 (UTC) FILETIME=[2FBBA760:01C8892D] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Tue, 18 Mar 2008 14:20:54 -0500 (CDT) Cc: sidr@ietf.org, Sandy Murphy Subject: Re: [Sidr] On Time and Frequency of ROA Publication X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, 18 Mar 2008, Danny McPherson wrote: > > On Mar 18, 2008, at 12:41 PM, Sandy Murphy wrote: > >>> Second, if a new ROA is required and that information is employed >>> directly by the routing system and validated by a protocol such as >>> SBGP, would this model require that each routing entry for which >>> a ROA exists be readvertised every ~24 hours? >> >> I don't see why a new ROA would necessitate a new BGP Update. >> >> Can you say why that would be necessary? >> >> The Update should still be in the Adj-RIB-In, and the new ROA (absent >> changes in authorization, of course) should authorize it as well >> as the old ROA. > > Ahh, that's perhaps where I'm missing something. > > So, intermediate systems validate based on the ROA and > it has a periodic expire with the associated certificate, doesn't > the refreshed certificate need to be propagated each time it's > refreshed - if employing such a capability in an inter-domain > routing protocol? That's the reason behind the need to (r)sync with databases everywhere periodically. Like creating your filters from IRRs each evening. --Sandy > > -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 sidr-bounces@ietf.org Tue Mar 18 13:10:19 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E93E528C17C; Tue, 18 Mar 2008 13:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.434 X-Spam-Level: X-Spam-Status: No, score=-100.434 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id az4PpV0BKBAb; Tue, 18 Mar 2008 13:10:18 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2D1C3A6A66; Tue, 18 Mar 2008 13:10:18 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5333A6A04 for ; Tue, 18 Mar 2008 13:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UN8m1nDn83N1 for ; Tue, 18 Mar 2008 13:10:13 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id CD7AD3A6B0E for ; Tue, 18 Mar 2008 13:10:12 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id E11372680A3; Tue, 18 Mar 2008 14:07:55 -0600 (MDT) Received: from [10.0.9.134] (bedford.lex.arbor.net [204.118.128.2]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 18 Mar 2008 14:07:55 -0600 (MDT) (envelope-from danny@tcb.net) Message-Id: From: Danny McPherson To: Sandra Murphy In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 18 Mar 2008 14:07:40 -0600 References: <20080318184147.09A2F3F47F@pecan.tislabs.com> <00F63B85-7653-44B8-95DD-C45C4576EF5D@tcb.net> X-Mailer: Apple Mail (2.919.2) Cc: sidr@ietf.org Subject: Re: [Sidr] On Time and Frequency of ROA Publication X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Mar 18, 2008, at 1:20 PM, Sandra Murphy wrote: > > That's the reason behind the need to (r)sync with databases > everywhere periodically. Like creating your filters from IRRs each > evening. Yes, but I'm saying, IF the ROA/expiry data is included in a secure routing protocol's route update messages and is to be validated by intermediate systems, then such periodic refresh timers could have considerable implications on the stability of the routing system. -danny _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 18 13:18:48 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BF793A6F21; Tue, 18 Mar 2008 13:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.686 X-Spam-Level: X-Spam-Status: No, score=-100.686 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZW+NYpbzMkw; Tue, 18 Mar 2008 13:18:47 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34B403A6E2E; Tue, 18 Mar 2008 13:18:47 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F46F3A6C2C for ; Tue, 18 Mar 2008 13:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-kfs3DZEtp4 for ; Tue, 18 Mar 2008 13:18:45 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 5CE483A6840 for ; Tue, 18 Mar 2008 13:18:45 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m2IKGSN4030651; Tue, 18 Mar 2008 15:16:28 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m2IKGSCb010825; Tue, 18 Mar 2008 15:16:28 -0500 Received: from localhost ([157.185.81.151]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Mar 2008 16:16:27 -0400 Date: Tue, 18 Mar 2008 16:16:27 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Danny McPherson In-Reply-To: Message-ID: References: <20080318184147.09A2F3F47F@pecan.tislabs.com> <00F63B85-7653-44B8-95DD-C45C4576EF5D@tcb.net> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 18 Mar 2008 20:16:27.0831 (UTC) FILETIME=[F268AC70:01C88934] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Tue, 18 Mar 2008 15:16:28 -0500 (CDT) Cc: sidr@ietf.org Subject: Re: [Sidr] On Time and Frequency of ROA Publication X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, 18 Mar 2008, Danny McPherson wrote: > > On Mar 18, 2008, at 1:20 PM, Sandra Murphy wrote: >> >> That's the reason behind the need to (r)sync with databases everywhere >> periodically. Like creating your filters from IRRs each evening. > > Yes, but I'm saying, IF the ROA/expiry data is included in > a secure routing protocol's route update messages and is Ah. Well, that's a possible future direction, but we're not there yet. > to be validated by intermediate systems, then such periodic > refresh timers could have considerable implications on the > stability of the routing system. In any distribution of the ROA/certs, you need to take some care in operational matters - creating the new cert with some overlap in validity timing seems desirable, getting the new ROA distributed in time whether through repositories or BGP or whatever, and error conditions (see Geoff's draft) that have a "validates but against expired ROA" case coupled with local policy as to whether to accept that or not, etc. --Sandy > > -danny > > _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 18 13:32:43 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBEA828C640; Tue, 18 Mar 2008 13:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.677 X-Spam-Level: X-Spam-Status: No, score=-100.677 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VX8kjEzzaSjW; Tue, 18 Mar 2008 13:32:43 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F28D28C611; Tue, 18 Mar 2008 13:32:42 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FC4328C60A for ; Tue, 18 Mar 2008 13:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgXLT4FIsom2 for ; Tue, 18 Mar 2008 13:32:40 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id C496328C611 for ; Tue, 18 Mar 2008 13:32:40 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JbiRy-0002yU-4I; Tue, 18 Mar 2008 16:30:22 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4D22EF37-FCF2-48BB-889F-8FE8C1 7A1B04@aepnetworks.com> <47DE5161.3030104@ripe.net> <004201c88855$c77f8540$6e00a8c0@ad.redback.com> <47DF04FB.9020103@apnic.net> Date: Tue, 18 Mar 2008 16:29:05 -0400 To: Sandra Murphy From: Stephen Kent Cc: "'Michele \(Mike\) Hjorleifsson'" , sidr@ietf.org Subject: Re: [Sidr] Rsync X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 1:25 PM -0400 3/18/08, Sandra Murphy wrote: >On Tue, 18 Mar 2008, Stephen Kent wrote: > >>At 9:55 AM +1000 3/18/08, Robert Loomans wrote: > >> >>It has been suggested that access to repositories might be >>TLS-protected, even though the data is intended to be widely >>available. The motivation is that requiring a TLS credential (issued >>under the RPKI) could be used to reject DoS attacks by complete >>outsiders. > >Can you say more about the TLS credential issued under the RPKI? > >First - so the credential would point in some way to the resource >held as the source of the access? it would, implicitly, as do all RPKI certs, but the only check needed here is that it is a valid cert under the RPKI. >Second - are you suggesting that a repository would not be open to >those who were not resource holders? (Like: academics looking for >allocation patterns for research purposees would be just as denied >as the trolls looking for allocation patters for commercial >purposes?) the primary function of a repository is to provide certs, CRLs, ROAs, etc. to ISPs. access to anyone else is a secondary issue. >Third - do commercial entities running global repositories as a >service have a way to get such a TLS credential? we have not discussed the need for such third parties to operate repositories. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 18 14:42:56 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B072A3A6F10; Tue, 18 Mar 2008 14:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.694 X-Spam-Level: X-Spam-Status: No, score=-100.694 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsGHCnkU6XOf; Tue, 18 Mar 2008 14:42:55 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D18D23A68F3; Tue, 18 Mar 2008 14:42:55 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF86D3A6D4E for ; Tue, 18 Mar 2008 14:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNxtE6Nk57tG for ; Tue, 18 Mar 2008 14:42:54 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 8A36C3A6BC3 for ; Tue, 18 Mar 2008 14:42:53 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JbjXw-0006CA-3M; Tue, 18 Mar 2008 17:40:36 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <8EA7888C-5E33-4223-B71B-A5EC7F3E8A9B@tcb.net> References: <8EA7888C-5E33-4223-B71B-A5EC7F3E8A9B@tcb.net> Date: Tue, 18 Mar 2008 17:40:53 -0400 To: Danny McPherson From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [Sidr] On Time and Frequency of ROA Publication X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 9:05 PM -0600 3/17/08, Danny McPherson wrote: >In reading draft-ietf-sidr-cp-03, and S 2.3 specifically, I have >a couple questions: >"A new ROA will be published before a predecessor ROA has expired, or >within 24 hours after an address space holder has changed the set of >ASes that is authorized to advertise the address blocks it holds." >What do folks believe would be normal behavior in a system if >the CA and a new ROA were not available for some extended >period of time? For example, some natural disaster occurred? >I know an individual RP could "opt out", but that's not realistic for >Internet-wide deployment. > >Second, if a new ROA is required and that information is employed >directly by the routing system and validated by a protocol such as >SBGP, would this model require that each routing entry for which >a ROA exists be readvertised every ~24 hours? I understand how >an offline system could suppress certificate updates, but not if this >information is directly employed by the routing system itself. Each resource holder is expected ton issue a ROA with a lifetime based on the holder's perception of the duration of the binding. For many (most?) folks, the binding between them and the AS authorized to originate a route to the prefix(es) in question is long lived, and the ROA (and associated cert) will be similarly long lived. However, as soon as the binding is no longer valid. the resource holder revokes the ROA by issuing a CRL. Thus the primary timeliness issue here is the frequency with which RPs fetch repository entries and discover new ROAs (and matching certs) and CRLs. The admonition to publish a new ROA that overlaps the old one is a way to avoid gaps and not require tight synchronization. Also note that a ROA authorizes an AS to originate a route for the prefix. One can publish a ROA for an AS that will originate a route only in case of an emergency, in anticipation of an advertisement being sent. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 18 15:02:52 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504853A6FB0; Tue, 18 Mar 2008 15:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.643 X-Spam-Level: X-Spam-Status: No, score=-100.643 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wR1m5ufvRDTh; Tue, 18 Mar 2008 15:02:51 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D89A3A6F9C; Tue, 18 Mar 2008 15:02:46 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6233A6F9C for ; Tue, 18 Mar 2008 15:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d272xt6bxH7K for ; Tue, 18 Mar 2008 15:02:41 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id A73893A6A56 for ; Tue, 18 Mar 2008 15:02:38 -0700 (PDT) Received: from dhcp6.potaroo.net (dhcp6.potaroo.net [203.10.60.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 1281CD5F2D; Wed, 19 Mar 2008 08:00:19 +1000 (EST) Message-ID: <47E03B72.3040301@apnic.net> Date: Wed, 19 Mar 2008 09:00:18 +1100 From: Geoff Huston User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Sandra Murphy References: <4D22EF37-FCF2-48BB-889F-8FE8C1 7A1B04@aepnetworks.com> <47DE5161.3030104@ripe.net> <004201c88855$c77f8540$6e00a8c0@ad.redback.com> <47DF04FB.9020103@apnic.net> In-Reply-To: Cc: "'Michele \(Mike\) Hjorleifsson'" , sidr@ietf.org Subject: Re: [Sidr] Rsync X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > On Tue, 18 Mar 2008, Stephen Kent wrote: > >> At 9:55 AM +1000 3/18/08, Robert Loomans wrote: > >> It has been suggested that access to repositories might be >> TLS-protected, even though the data is intended to be widely >> available. The motivation is that requiring a TLS credential (issued >> under the RPKI) could be used to reject DoS attacks by complete >> outsiders. > Perhaps the clarifying question is: are you talking about read access or write access? The comments I've seen that support the notion of no need for TLS support appear to refer to read access, where anyone can be a relying party and the combination of manifests and digital signatures on retrieved objects is sufficient to ensure that the relying party can determine the completeness and validity of the retrieved information. The comments I've seen in favour of TLS appear to refer to write access where a CA or EE has outsouced the publication repository management function to a third party and there may be some need for a secured channel of write access as a means of DOS protection. The drafts on this topic (draft-huston-sidr-repos-struct-01.txt, and draft-ietf-sidr-res-certs-09.txt) refer only to read access. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 18 19:11:58 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7F13A6E61; Tue, 18 Mar 2008 19:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.443 X-Spam-Level: X-Spam-Status: No, score=-100.443 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1JWWW4AiiQf; Tue, 18 Mar 2008 19:11:56 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 858533A6E09; Tue, 18 Mar 2008 19:11:51 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 566623A6B05 for ; Tue, 18 Mar 2008 19:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-QLkfeEqFtM for ; Tue, 18 Mar 2008 19:11:49 -0700 (PDT) Received: from aep-us-dc-01.aep-net.com (unknown [63.139.155.212]) by core3.amsl.com (Postfix) with ESMTP id E444E3A6E2A for ; Tue, 18 Mar 2008 19:11:28 -0700 (PDT) Received: from [172.16.50.199] ([76.110.31.20]) by aep-us-dc-01.aep-net.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Mar 2008 22:09:11 -0400 Message-Id: <1FC11487-D4DE-4B36-95F9-53AF264E38A7@aepnetworks.com> From: "Michele (Mike) Hjorleifsson" To: Geoff Huston In-Reply-To: <47E03B72.3040301@apnic.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 18 Mar 2008 22:09:07 -0400 References: <4D22EF37-FCF2-48BB-889F-8FE8C1 7A1B04@aepnetworks.com> <47DE5161.3030104@ripe.net> <004201c88855$c77f8540$6e00a8c0@ad.redback.com> <47DF04FB.9020103@apnic.net> <47E03B72.3040301@apnic.net> X-Mailer: Apple Mail (2.919.2) X-OriginalArrivalTime: 19 Mar 2008 02:09:11.0314 (UTC) FILETIME=[38D3E720:01C88966] Cc: sidr@ietf.org Subject: Re: [Sidr] Rsync X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org I believe the conversation was centered around write access, to ensure an unauthorized individual couldnt corrupt the repository On Mar 18, 2008, at 18:00 , Geoff Huston wrote: >> On Tue, 18 Mar 2008, Stephen Kent wrote: >>> At 9:55 AM +1000 3/18/08, Robert Loomans wrote: >> >>> It has been suggested that access to repositories might be >>> TLS-protected, even though the data is intended to be widely >>> available. The motivation is that requiring a TLS credential >>> (issued >>> under the RPKI) could be used to reject DoS attacks by complete >>> outsiders. > > > Perhaps the clarifying question is: are you talking about read > access or write access? > > The comments I've seen that support the notion of no need for TLS > support appear to refer to read access, where anyone can be a > relying party and the combination of manifests and digital > signatures on retrieved objects is sufficient to ensure that the > relying party can determine the completeness and validity of the > retrieved information. > > The comments I've seen in favour of TLS appear to refer to write > access where a CA or EE has outsouced the publication repository > management function to a third party and there may be some need for > a secured channel of write access as a means of DOS protection. > > The drafts on this topic (draft-huston-sidr-repos-struct-01.txt, and > draft-ietf-sidr-res-certs-09.txt) refer only to read access. > > > _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Mar 18 19:53:42 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D26828C2CE; Tue, 18 Mar 2008 19:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.647 X-Spam-Level: X-Spam-Status: No, score=-100.647 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQEKKVZj7SYT; Tue, 18 Mar 2008 19:53:39 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803C23A6975; Tue, 18 Mar 2008 19:53:39 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11F3E3A63EC for ; Tue, 18 Mar 2008 19:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1b0G2JZkdg5 for ; Tue, 18 Mar 2008 19:53:38 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 3BF033A69CD for ; Tue, 18 Mar 2008 19:53:37 -0700 (PDT) Received: from [202.12.29.209] (dhcp209.apnic.net [202.12.29.209]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id AAF10D5F2D; Wed, 19 Mar 2008 12:51:16 +1000 (EST) Message-ID: <47E07FA3.7040209@apnic.net> Date: Wed, 19 Mar 2008 12:51:15 +1000 From: Robert Loomans Organization: APNIC - http://www.apnic.net/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: "Michele (Mike) Hjorleifsson" References: <4D22EF37-FCF2-48BB-889F-8FE8C1 7A1B04@aepnetworks.com> <47DE5161.3030104@ripe.net> <004201c88855$c77f8540$6e00a8c0@ad.redback.com> <47DF04FB.9020103@apnic.net> <47E03B72.3040301@apnic.net> <1FC11487-D4DE-4B36-95F9-53AF264E38A7@aepnetworks.com> In-Reply-To: <1FC11487-D4DE-4B36-95F9-53AF264E38A7@aepnetworks.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=C6B3AE7E; url=http://robert.loomans.org/0xC6B3AE7E.asc Cc: sidr@ietf.org Subject: Re: [Sidr] Rsync X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0121207722==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0121207722== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070509070606070408050903" This is a cryptographically signed message in MIME format. --------------ms070509070606070408050903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Michele (Mike) Hjorleifsson wrote: > I believe the conversation was centered around write access, to ensure > an unauthorized individual couldnt corrupt the repository "the repository" is, I think, the crux of the issue here: there isn't just one repository. The current architecture is that each player in this system will be publishing to their own repository or to a repository hosted by someone on their behalf. Each of the RIRs will have a repository, each of their members that run their own certifying infrastructure will have their own repository, etc. The burden of synchronising from all the repositories in existence is expected to be mitigated somewhat by various parties, including APNIC, running aggregated caches. At present, there is no draft/spec/whatever standardising how provide a hosted repository to 3rd parties. So the issue of write access to "the repository" reduces to write access to your own repository... which is a very similar to discussing write access to your website: the details will vary depending on whether you host it yourself or use a hosting service, but you would hope that suitable access control would be in place :) Cheers, Rob -- Robert Loomans Email: robertl@apnic.net Senior Software Engineer, APNIC Phone: +61 7 3858 3100 http://www.apnic.net Fax: +61 7 3858 3199 --------------ms070509070606070408050903 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCC BW8wggRXoAMCAQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UE ChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5h Z2VyQGFwbmljLm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNV BAYTAkFQMREwDwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTAL BgNVBAUTBDg5NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjF QP4OmyB73NE86ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs 02JKEd4Kwap6eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH 0PvpZNWiV3uBqhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR 7r2SJDQ8SXiUJy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+ uyZcsqAE7VVX0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAA MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklD IENsaWVudCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsG A1UdIwSBszCBsIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFV MQ4wDAYDVQQKEwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQD EyVBUE5JQyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkB FhNjYW1hbmFnZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0 MB4GA1UdEgQXMBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0 cHM6Ly93d3cuYXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0 dHBzOi8vd3d3LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZo dHRwczovL3d3dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOC AQEAhtnqJUiql+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq 32x4R8YHDgfUwq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiC gPx/wQ72Eyj6DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgk f2Qk5n8RiNEpzzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKT H3fAz9RQC3zprZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjCCBW8wggRXoAMC AQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMx GzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmlj Lm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNVBAYTAkFQMREw DwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTALBgNVBAUTBDg5 NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjFQP4OmyB73NE8 6ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs02JKEd4Kwap6 eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH0PvpZNWiV3uB qhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR7r2SJDQ8SXiU Jy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+uyZcsqAE7VVX 0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAAMBEGCWCGSAGG +EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklDIENsaWVudCBD ZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsGA1UdIwSBszCB sIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFVMQ4wDAYDVQQK EwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQDEyVBUE5JQyBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkBFhNjYW1hbmFn ZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0MB4GA1UdEgQX MBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0cHM6Ly93d3cu YXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0dHBzOi8vd3d3 LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwczovL3d3 dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAhtnqJUiq l+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq32x4R8YHDgfU wq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiCgPx/wQ72Eyj6 DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgkf2Qk5n8RiNEp zzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKTH3fAz9RQC3zp rZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjGCA8YwggPCAgEBMIGVMIGOMQsw CQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNl czEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAG CSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmljLm5ldAICIwMwCQYFKw4DAhoFAKCCAgUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwMzE5MDI1MTE1WjAj BgkqhkiG9w0BCQQxFgQUaf9sEOi95lXcfUJCctuUDpj+pD4wUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgaYGCSsGAQQBgjcQBDGBmDCBlTCBjjELMAkGA1UEBhMCQVUxDjAMBgNV BAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNVBAMTJUFQTklD IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0BCQEWE2NhbWFu YWdlckBhcG5pYy5uZXQCAiMDMIGoBgsqhkiG9w0BCRACCzGBmKCBlTCBjjELMAkGA1UEBhMC QVUxDjAMBgNVBAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNV BAMTJUFQTklDIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0B CQEWE2NhbWFuYWdlckBhcG5pYy5uZXQCAiMDMA0GCSqGSIb3DQEBAQUABIIBAA9nQnqoF4dc LwFv6V87G0Q01zqPXURPqCdVY6Rr7c4Nmn+KqX2PBo4CWbv3VYDg1HmIeACWMu5BZ82siG7g UTOTYz60J//3VNVcf6x3bZx0AwMmvJKNN5t6JNHGjdt1ZvhABB3ykQMdccQnfmzi7tX3YZyU MeIBq7d4GlYnqEJn3rKM/A0gB2OwRChiJs1bT5rpt7RFl5V8R8oK+jFCWT+7Z/aNBZmOVjfC 4rCdbfUt25JnX/szA18cDardQxFAdJwd0TUoxWV4kxeFaNKbwgpxH5gG0pZIushRRDbO9cTs AKH7D3SrhmUQ5r2exfjXuo1tV1JNxlKQxpP+sw1b8M8AAAAAAAA= --------------ms070509070606070408050903-- --===============0121207722== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============0121207722==-- From sidr-bounces@ietf.org Wed Mar 19 10:16:38 2008 Return-Path: X-Original-To: ietfarch-sidr-archive@core3.amsl.com Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2DBB3A6E6E; Wed, 19 Mar 2008 10:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.677 X-Spam-Level: X-Spam-Status: No, score=-100.677 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQ61UBeCV8Js; Wed, 19 Mar 2008 10:16:37 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984543A6F6E; Wed, 19 Mar 2008 10:16:34 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45AE33A6F66 for ; Wed, 19 Mar 2008 10:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RXW81NCX2HS for ; Wed, 19 Mar 2008 10:16:32 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 4A1AD28C2D8 for ; Wed, 19 Mar 2008 10:16:23 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Jc1rZ-0006xF-4v; Wed, 19 Mar 2008 13:14:05 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <47E03B72.3040301@apnic.net> References: <4D22EF37-FCF2-48BB-889F-8FE8C1 7A1B04@aepnetworks.com> <47DE5161.3030104@ripe.net> <004201c88855$c77f8540$6e00a8c0@ad.redback.com> <47DF04FB.9020103@apnic.net> <47E03B72.3040301@apnic.net> Date: Wed, 19 Mar 2008 13:14:19 -0400 To: Geoff Huston From: Stephen Kent Cc: "'Michele \(Mike\) Hjorleifsson'" , sidr@ietf.org Subject: Re: [Sidr] Rsync X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 9:00 AM +1100 3/19/08, Geoff Huston wrote: >>On Tue, 18 Mar 2008, Stephen Kent wrote: >> >>>At 9:55 AM +1000 3/18/08, Robert Loomans wrote: >> >>>It has been suggested that access to repositories might be >>>TLS-protected, even though the data is intended to be widely >>>available. The motivation is that requiring a TLS credential (issued >>>under the RPKI) could be used to reject DoS attacks by complete >>>outsiders. >> > > >Perhaps the clarifying question is: are you talking about read >access or write access? With regard to DoS concerns, I was talking about read access. >The comments I've seen that support the notion of no need for TLS >support appear to refer to read access, where anyone can be a >relying party and the combination of manifests and digital >signatures on retrieved objects is sufficient to ensure that the >relying party can determine the completeness and validity of the >retrieved information. I agree that write access poses greater access control concerns in general, but we should care about DoS in the context of read access. Since I was the one who made the comments, I guess I didn't make them clearly enough :-). >The comments I've seen in favour of TLS appear to refer to write >access where a CA or EE has outsouced the publication repository >management function to a third party and there may be some need for >a secured channel of write access as a means of DOS protection. Yes. There are lots of options here, and it is not clear if we need to have one standard way to do this, or just say that suitable access controls need to be employed, and give examples of reasonable ways to achieve such. >The drafts on this topic (draft-huston-sidr-repos-struct-01.txt, and >draft-ietf-sidr-res-certs-09.txt) refer only to read access. right. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr