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

Terry Manderson <> Tue, 12 June 2012 00:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4473821F8550 for <>; Mon, 11 Jun 2012 17:28:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hrokn+NkepDS for <>; Mon, 11 Jun 2012 17:28:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 90D6421F849A for <>; Mon, 11 Jun 2012 17:28:25 -0700 (PDT)
Received: from ([]) by ([]) with mapi; Mon, 11 Jun 2012 17:28:25 -0700
From: Terry Manderson <>
To: "Roque Gagliano (rogaglia)" <>
Date: Mon, 11 Jun 2012 17:28:20 -0700
Thread-Topic: [sidr] draft-ymbk-rpki-grandparenting-00.txt
Thread-Index: AQHNRXgOmeMHLOI6skGjzaABNoC0K5b12Zn4
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: yes
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3422341700_36292392"
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 00:28:26 -0000

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.