Re: [sidr] draft-ymbk-rpki-grandparenting-00.txt

"Murphy, Sandra" <> Tue, 12 June 2012 16:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 124AE21F8617 for <>; Tue, 12 Jun 2012 09:28:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.227
X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C4DrSQA3iGge for <>; Tue, 12 Jun 2012 09:28:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 245BE21F8613 for <>; Tue, 12 Jun 2012 09:28:16 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id q5CGPMfp022645; Tue, 12 Jun 2012 11:25:22 -0500
Received: from ([]) by (8.13.8/8.13.8) with ESMTP id q5CGPKFn014879; Tue, 12 Jun 2012 11:25:21 -0500
Received: from ([2002:9db9:506b::9db9:506b]) by ([::1]) with mapi id 14.01.0355.002; Tue, 12 Jun 2012 12:25:09 -0400
From: "Murphy, Sandra" <>
To: Terry Manderson <>, "Roque Gagliano (rogaglia)" <>
Thread-Topic: [sidr] draft-ymbk-rpki-grandparenting-00.txt
Thread-Index: AQHNQ+zWiDAxYMZ0Bkmzxjjf+kJXoZbunymAgAAhOYCAARaigIAA1EwAgAV0bQCAAMR0YQ==
Date: Tue, 12 Jun 2012 16:25:09 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: sidr wg list <>
Subject: Re: [sidr] draft-ymbk-rpki-grandparenting-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Jun 2012 16:28:18 -0000

Speaking as a regular ol' wg member:


>So if both AS 'C' and AS 'G' originate the route and
>both ROAs may exist, then you have a MOAS event.

The architecture specifically allows there to be multiple ROAs for a single prefix.  That was a deliberate choice from long, long ago.

(For a look at the number of occurrences of multiple origins, you can look at  (And thanks to HE for that site, btw.)  It gives a clue into some reasons why multiple origins might occur.)

--Sandy, speaking as regular ol' member

From: [] on behalf of Terry Manderson []
Sent: Monday, June 11, 2012 8:28 PM
To: Roque Gagliano (rogaglia)
Cc: sidr wg list
Subject: Re: [sidr] draft-ymbk-rpki-grandparenting-00.txt

Hi Roque,

On 8/06/12 11:10 PM, "Roque Gagliano (rogaglia)" <> wrote:

> This is more a question for Randy.
> IMHO, his text says both:
> "A may certify G's resources, or issue one or more EE certificates and ROAs
> for G's resources. Which is done is a local matter between A and G."

Fair enough, although I'm not so sure that it makes sense to

>> BTW, My understanding of that paragraph was about situations where you have
>> trust anchors that overlap.
> Your english is definitely better than mine, but I do not find any reference
> to trust anchors. I think it applies generally to any registry database.

My understanding comes from probably a bad memory of the early discussions
relating to such 'uniqness' issues.

>>> My understanding of Randy's proposal is that both C and G will have for a
>>> period of time the "right of use" for the address space.
>> The idealistic stance might be that the RPKI and associated drafts should
>> not recommend a situation of ambiguity. Being able to have two different
>> ROAs (with different ASNs) for the same prefix issued by EE certs from
>> different res certs (thus different private keys) seems like it is making
>> life tough for the relying party.
> How would a RP check this? (think particularly on bottom-up fetch +
> validation)

As far as I can tell, without experimentation, is that any match would work.

So if both AS 'C' and AS 'G' originate the route and both ROAs
may exist, then you have a MOAS event.

> What the RFC 6487 security section is basically saying is that you should be
> at least as good as your registration back-end.

I think you are trying say "we know that G has the resource, but are going
to pretend they don't so we can cut a ROA for G, so that their routing works
but we can be lazy on changing certs to C."

That might not be a bad thing, if there was some way to inhibit C from
creating a ROA, that might mess with G. The idea that securing routing is
based on 'a legitimate holder' [rfc6480] being able to authorize one or more
ASes of its choosing appears to be relaxed in this text. Is that a slippery

>> Is it?
>> So step wise since G is moving ISPs from C to A (and they originate the
>> route on G's behalf):
>> 1) "C" has the, presumably ROA issued for, AS-'C'
>> ( AS-"C" route VALID)
>> 1.5) Worst case of "A" is slow between revoking/reissuing C's cert (all
>> routes UNKNOWN, but still routable)
> Here you break. UNKNOWN/NOT FOUND may have a different policy (loc. pref.
> ,etc.).

OK. lets just say "UNKNOWN". I feel more comfortable in knowing that a RP
can make decision based on unambiguous information. Be that implemented in
local policy application (local pref etc) or otherwise.

> I have not written RP software, but I believe it will be harmless as it would
> validate.  I do not believe iit breaks the CP document as the only reference
> to "unique holder" that I found was in the abstract section.

Indeed. I always considered the holder to be very singular in nature.

> All in all, I think it is good that Randy raised this issue. I wonder if we
> need another document or add it to the "Use Case" document as it has not yet
> been ship to the IESG.

Good question.