Re: [sidr] Questions about draft-huston-rpki-validation-01
Geoff Huston <gih@apnic.net> Wed, 12 March 2014 06:14 UTC
Return-Path: <gih@apnic.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872961A0574 for <sidr@ietfa.amsl.com>; Tue, 11 Mar 2014 23:14:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.338
X-Spam-Level:
X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9v3VzECvRf9 for <sidr@ietfa.amsl.com>; Tue, 11 Mar 2014 23:13:57 -0700 (PDT)
Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:3::243]) by ietfa.amsl.com (Postfix) with SMTP id 261BE1A08E2 for <sidr@ietf.org>; Tue, 11 Mar 2014 23:13:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=zwzGooe03e9qmMlxAePTcpHG3OlkJ/EfHEFiA/lw4dI=; b=eseku+ICPEIm8Q7LtXBvVvoVp855QScMbopjp3ZrJSBD4cL5WqXfIh6u1lvFhm2IIzC6+FtmjDlX6 kZzG3LLtBQkP8Q875QVDpv2yrOWYbcgc1PUT2eUYW4h07pZuf20N7MUwY8x6OQvfkSd7kOuOCNFbXc FH6u4jeSIKDOniXE=
Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Wed, 12 Mar 2014 16:12:21 +1000 (EST)
Received: from [10.207.196.3] (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 12 Mar 2014 16:13:47 +1000
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Geoff Huston <gih@apnic.net>
In-Reply-To: <aa922cfa32d64b01ad85a472faa9356b@BLUPR09MB053.namprd09.prod.outlook.com>
Date: Wed, 12 Mar 2014 17:13:37 +1100
Content-Transfer-Encoding: quoted-printable
Message-ID: <F69C5324-C865-46FB-9B49-940B47F29ADD@apnic.net>
References: <aa922cfa32d64b01ad85a472faa9356b@BLUPR09MB053.namprd09.prod.outlook.com>
To: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/pV6GsjnBa07RiO1s-gEQvFCMW4M
Cc: George Michaelson <ggm@apnic.net>, sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] Questions about draft-huston-rpki-validation-01
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Mar 2014 06:14:00 -0000
Hi Srinam, Thanks for your questions - let me try and answer them as best I can... > I went through your -01 draft and the SIDR presentation slides from last week once again, > and have the following questions: > > (1) An update with prefix-origin pair {5.0.0.0/24, AS64511} is received. > There is a ROA: {5.0.0.0/22, maxLength = 24; AS64511} in the RPKI. > However, it is signed using a certificate that is “valid” only for resource {5.0.0.0/24}. > In this case, is it the intent of your alternate validation model to ascertain that > the above ROA is partially valid, and accordingly prefix-origin pair {5.0.0.0/24, AS64511} is “Valid”? If I understand your question, you are painting the picture where: The ROA says that AS64511 can announce 5.0.0.0/22 or any subset up to a /24 The EE cert that signed it has a resource extension of 5.0.0.0/24 (i.e. the ROA is overclaiming) And the CA that signed it has a resource extension set that encompasses 5.0.0.0/24 And the CA "above" it has a resources extension that encompasses 5.0.0.0/24 etc to the trust anchor So if we said "is the UPDATE 5.0.0.0/24 valid" then given that 5.0.0.0/24 is contained in the ROA, and the same prefix is contained in all the certs from the EE cert to a TA in an otherwise valid validation path, then the answer would be YES Although I note that the draft did NOT explicitly talk about the relationship between a ROA and the EE cert that signed it. It only talked about the treatment of the resource extensions in the pair-wise comparison of certificates in the validation path. In your question you've extended that same approach to the relationship between the EE cert that signed the ROA and the ROA. I think that is a consistent extension, but its a matter that should be further considered. > > (2) Let us say, there is a ROA: {1.0.0.0/24, 2.0.0.0/22, 3.0.0.0/20; AS64500} in the RPKI. > But this ROA is signed using a certificate that is “valid” only for resources {1.0.0.0/24, 3.0.0.0/20} > that is a subset of the prefixes listed in the ROA. > In this case, is it the intent of your alternate validation model to ascertain that > the above ROA is partially valid, and accordingly prefix-origin pairs > {1.0.0.0/24, AS64500} and {3.0.0.0/20, AS64500} are “Valid”? In this example you are again painting a picture of a ROA that "overclaims" as compared to the resources listed in the EE certificate that signed it. Assuming that there are validation paths for 1.0.0.0/24 and 3.0.0.0/24 between a TA and the EE cert then yes, by the same reasoning as the answer to the previous question I would say that a consistent answer is that these two updates would be accepted as "valid" (with the same caveat that this is an extension to the described approach to certificate validation, but an extension that I personally am comfortable with) > > (3) On slide #18, do you need to require “Certificates 1 through n-1 are also “valid” > according to this same criterion”? You are not validating them at this point. > You are only validating Certificate ‘n’ for *a given INR*. > Is it not enough to require that “the resources in the INR extension of > Certificate x must subsume the given INR” for each x (individually); x=1, 2, 3, …, n? I was taking the text of RFC3779 that defined the certificate validity (slide 3) and was illustrating the difference in that text were we to use this approach. I think your formulation of the text has the same semantic intent as the text on slide 18, but your text highlights the difference from RFC3779, while I was trying to illustrate what would need to change from the original validation definition. Either that or I have not understood your question! If so, could you explain this a bit more? regards, Geoff
- [sidr] Questions about draft-huston-rpki-validati… Sriram, Kotikalapudi
- Re: [sidr] Questions about draft-huston-rpki-vali… Geoff Huston
- Re: [sidr] Questions about draft-huston-rpki-vali… Sriram, Kotikalapudi
- Re: [sidr] Questions about draft-huston-rpki-vali… Sriram, Kotikalapudi
- Re: [sidr] Questions about draft-huston-rpki-vali… Geoff Huston
- Re: [sidr] Questions about draft-huston-rpki-vali… Sriram, Kotikalapudi
- Re: [sidr] Questions about draft-huston-rpki-vali… Geoff Huston
- Re: [sidr] Questions about draft-huston-rpki-vali… Sriram, Kotikalapudi
- Re: [sidr] Questions about draft-huston-rpki-vali… Geoff Huston
- Re: [sidr] Questions about draft-huston-rpki-vali… Sriram, Kotikalapudi
- Re: [sidr] Questions about draft-huston-rpki-vali… Tim Bruijnzeels
- Re: [sidr] Questions about draft-huston-rpki-vali… Christopher Morrow
- Re: [sidr] Questions about draft-huston-rpki-vali… Geoff Huston
- Re: [sidr] Questions about draft-huston-rpki-vali… Christopher Morrow
- Re: [sidr] Questions about draft-huston-rpki-vali… Stephen Kent
- Re: [sidr] Questions about draft-huston-rpki-vali… Geoff Huston
- Re: [sidr] Questions about draft-huston-rpki-vali… Stephen Kent