[135403] in North American Network Operators' Group
Re: [arin-announce] ARIN Resource Certification Update
daemon@ATHENA.MIT.EDU (Joe Abley)
Mon Jan 24 21:02:16 2011
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <FFDCC932-AFD0-428F-9A50-B3B389D4532B@tcb.net>
Date: Mon, 24 Jan 2011 21:02:00 -0500
To: Danny McPherson <danny@tcb.net>
X-SA-Exim-Mail-From: jabley@hopcount.ca
Cc: NANOG Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On 2011-01-24, at 20:24, Danny McPherson wrote:
> <separate subject>=20
> Beginning to wonder why, with work like DANE and certificates in DNS
> in the IETF, we need an RPKI and new hierarchical shared dependency=20=
> system at all and can't just place ROAs in in-addr.arpa zone files =
that are=20
> DNSSEC-enabled.=20
In the case where (say)
RIR allocates 10.0.0.0/8 to A
A allocates 10.1.0.0/16 to B
B allocates 10.1.1.0/24 to C
there's a clear path of delegations in the DNS under IN-ADDR.ARPA from =
RIR -> A -> B -> C and this matches the chain of address assignments. If =
you adopt the convention that a secure delegation (a signed DS RRSet) is =
analogous to an RPKI signature over a customer certificate, then this =
seems vaguely usable.=20
But what about this case?
RIR allocates 10.0.0.0/8 to A
A allocates 10.0.0.0/16 to B
B allocates 10.0.0.0/24 to C
In this case the DNS delegations go directly from RIR to C; there's no =
opportunity for A or B to sign intermediate zones, and hence no =
opportunity for them to indicate the legitimacy of the allocation.
As a thought experiment, how would you see this working?
Joe=