Subject: On the IAB technical advice on the RPKI

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 13 Mar 2010 21:15:40 -0500

So what has me annoyed about the IAB advice is that they gave advice
about a particular means where they should have instead specified a
requirement.

http://www.ietf.org/mail-archive/web/ietf-announce/current/msg07028.html

" The reasoning is of a technological nature and is as follows. A
 single root for the certification hierarchy significantly reduces
 the risk of two or more parties accidentally (or maliciously)
 issuing conflicting certifications for the same address block,
 because a single authoritative entity at the top-level of the
 allocation hierarchy is authoritative for both (a) the allocation of
 the address block and (b) the cryptographic certification of the
 fact that it did indeed allocate that address block."

It is not necessary for the IAB to state any more than that it is
desirable to prevent accidental conflicting certifications. It should
not attempt to state anything more. It is not an expert body on X.509
infrastructure, it is a body which typically has one or at most two
experts in that field.

As it happens, having a single root does nothing to prevent accidental
conflicting certifications, not a sausage, nada, zip, nihil. The only
way to prevent accidental collisions is to have a validation mechanism
that checks signed data issued by IANA with signed data issued by the
RIRs.

Now you can conflate that with an X.509 PKI, but doing so means that
you have created completely new path validation semantics. So you have
all the disadvantages of using an existing PKI specification and none
of the advantages. It is not going to be possible to use existing
X.509 processing code without modification. Worse yet, attempting to
use path constraints to control conflicts means that the RIRs are
going to find it very difficult to apply the type of online/offline
key management we would want them to use. It is a design I have seen
before, the customer ended up expressing regret for the consequences
(but not enough regret to change to the alternative I had proposed
originally).

I find it very hard to believe that a system that is so tightly
coupled to the technology is going to prove sufficiently flexible to
be practical. My experience is that when you deploy crypto in a
situation that has not previously had crypto you suddenly discover a
wide range of unexpected deviations from the pattern expected.

Taking another look at this problem, I think I have found a solution
that dramatically reduces the deployment cost and risk for all
parties, eliminates the use of 'exotic' X.590v3 application and most
importantly, eliminates the need for most IP block holders to obtain a
signature key.

One of the important side benefits of this scheme is that the
resilience of the Internet routing layer is greatly enhanced. The risk
of BGP redirection through remapping of the IP-AS mapping is
eliminated for a large number of endpoints without any effort being
required on their part. If we do get to a point where there is a major
Internet meltdown due to kinetic attack, it is possible to
re-establish a major portion  of the routing tables from static data.

Here is how I would issue signed ownership statements for IP address blocks:

IANA, and the 5 RIRs establish standards based, independent PKIX pkis
with themselves as root authority (cost circa $40K if outsourced)
The 6 root PKIs cross certify. This means that at the end of the
process any of the six may be regarded as a root.

IANA and the 5 RIRs maintain a machine readable log of their actions
in both a consolidated and delta format. These are signed using online
keys that are generated at periodic (e.g. 1 year) intervals and signed
using the offline keys.

Every 24 hours (1 hour if necessary) a new delta file of the machine
readable log is signed and distributed
Every 7 days a new consolidated file is signed and distributed.

[Note here that the technical requirements imposed on the RIRs and
IANA are limited to the type of operation that can be reasonably be
performed with very minimal deviation from their current practice. It
may well be desirable for the format to support pre-dated transactions
so that block reassignments can be advertised in advance]

IANA signing statements allocate an entire block of IP addresses to a RIR.
RIR signing statements allocate a block of IP addresses to an AS
number OF RECORD, this need not be the actual assignment as far as BGP
is concerned

Unless we are in a 'defection' condition the validation rules for
determining if a signing statement is valid is to verify that the RIR
statement has a corresponding IANA allocation statement. Cross
references in the machine readable format may facilitate this.

In the unlikely case we are in a defection condition then an event has
occurred such that one or more of the RIRs no longer accepts the
authority of IANA. The scheme outlined is designed to 'soft-fail' in
this circumstance, effectively ensuring that a stalemate is achieved
until the RIRs and IANA are back in agreement.

The purpose of including this particular condition is not because IANA
is not trusted but because any single point of failure may be coerced.
Alternatively, any system that involves online crypto may be subject
to a physical attack. Rather than deploy $5 million plus worth of
physical protection, it is safer to establish a situation where there
is no single point of failure.

Note here that one significant advantage of this architecture is that
IP block holders do not need to obtain keys unless they wish to
reassign their blocks to another party on a temporary basis, use
anycast or perform similar activities. This is important for
deployment as it greatly reduces the number of parties that require a
key. or the use of secure BGP.

Only the larger and more sophisticated parties need establish an AS
holder key and deploy signature technology for the purpose of
authenticating IP block to AS number bindings. I am leaving out the
issue of routing table generation as that is a very different set of
issues.

The parties that do need to establish a signature key would cross
certify with one or other of the RIRs or IANA using a set of practices
that ensure that the holdership of the corresponding AS number is
validated. Again, an online/offline configuration is to be preferred.
Cross certification events would be noted in the RIR machine readable
log.

The way that I would manage a transition would be to advertise a
series of cut-off dates.

* On the first cut-off date any IP address block that had not been
observed as being allocated to an AAS number other than the AS number
of record would be flagged as 'locked' and could only then be assigned
to another AS number by means of a signed BGP request.

* On the second cut-off date, all IP address blocks would be marked locked

* On the third cutoff date, backbone routers would cease forwarding
unsigned BGP mappings for IP blocks.

If we adopted this plan it would be the first time that we had ever
transitioned an entire chunk of Internet infrastructure from an
insecure state to a state where security was now a requirement.

Unlike the IAB scheme, this one does not disrupt the existing trust
relationships between IANA and the RIRs. It does not create
inter-governmental concerns of increasing 'dominance'. Nor does it
create an incentive for someone to enter a SOC with a gun and tell
someone to hand over the crypto.

There can be a timetable for deployment, and that timetable can be
credibly short.

-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Mar 2010 08:24:41 +0900

Phillip Hallam-Baker wrote:

As was discussed already in this ML, RPKI is useless.

Even if an AS owning an address block is securely known, it does
not secure routing to the address block through other ASes.

							Masataka Ohta

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 15 Mar 2010 20:27:04 -0400

There is a big difference in real engineering (i.e. outside a
university) between a solution that only addresses part of a problem
and one that is 'useless'.

In this case it is much more important to restrict the application of
cryptography to problems that it solves well than to attempt to solve
every problem.

In observed attacks and in simulations, the IP-AS number attack is
much more significant than the routing layer attack in most
circumstances. The IP-AS attack is global, the effects of the routing
layer attack are local.

There are many security concerns that BGP security could address. The
only concerns for which a BGP security solution is essential is to
prevent Denial of Service attacks and to prevent hijacking of IPv4
space after exhaustion is reached.

I believe that the most likely scenario in which BGP security is
actually deployed is that the IPv4 space runs out and we then see a
huge increase in address block theft and bogon injection by spammers
and other malicious actors. I have deliberately crafted a solution
that can be applied in a 'save your ass' mode.

The routing level attack will remain, but that is only an issue for AS
networks that are not directly connected. Networks that are directly
connected are not going to be fooled by bogus routes, particular not
by routes that are several hops removed.

While that may seem a somewhat callous observation 'ok, so huge chunks
of the net can fail', the point is that we can avoid some of the more
painful consequences of critical infrastructure that relies on IP
connectivity collapsing through some fairly simple measures. We can
also avoid deadlock situations where the net falls down and we can't
bring it back because the routing tables are totally contaminated.

In practice though, the consequences of routing manipulation are
manageable. Worst case we can revert to the routing tables that worked
an hour ago. or a day ago and get to 95% normalcy.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 18 Mar 2010 07:02:41 +0900

>> and one that is 'useless'.

Perhaps, you don't recognize the fact that BGP routing is global.

>> circumstances.

I'm not sure what are the IP-AS attack and the routing layer attack
and whether you are worrying about attacks today or year 3010.

So, before continuing discussion, I think you should write a draft
precisely defining problems including the attacks. The draft may
be more than 100 pages long.

It should be noted, however, that, it is likely that I point out the
attacks are identical, if I have enough time to read everal lines of
the draft. Note that:

             A Profile for Route Origin Authorizations (ROAs) 
                     draft-ietf-sidr-roa-format-06.txt 

says:

   The primary purpose of the Internet IP Address and AS Number Resource 
   Public Key Infrastructure (RPKI) system is to improve routing 
   security. 

>> space

The point of previous discussion was that RPKI is useless for such
prevention. Read the ML log.

>> after exhaustion is reached.

With A+P, it will be reached in year 3010 or later.

						Masataka Ohta

---

From: Stephen Kent <[email-masked]>
Date: Thu, 18 Mar 2010 13:28:10 -0400

>about a particular means where they should have instead specified a

Phil,

I am not commenting on your proposal, but I do want to make a few 
observations that are relevant to this discussion.

I believe that the point the IAB was making is that if each RIR acts 
as a TA, any one of them could make an error (or suffer a compromise) 
that would allow for conflicting certs to be issued below the 
affected RIR. The certs used for the RPKI include RFC 3779 
extensions. If IANA acts as the only TA, then it will issue certs to 
the RIRs representing their allocations from IANA. Unless IANA makes 
an error in this cert issuance procedure (which should be aligned 
with its allocation of address space to the RIRs), then there can be 
no (undetected) conflicts among the RIRs re resource holdings. Also 
recall that IANA needs to act as a TA anyway, for unallocated, 
legacy, and reserved address space. So the choice the IAB was 
addressing was one TA vs. six.

You commented that using X.509 certs in this context requires 
"completely new path validation semantics." The semantics are 
well-defined in RFC 3779, which was issued in June 2004. I also 
observe that OpenSSL already supports cert path validation using 3779 
extensions, and has done so for at least a couple of years. Note also 
that the RPs here are primarily ISPs. They will use software that 
yields outputs consistent with their goals of origin AS validation. 
Based on the SIDR WG activities, this means validating ROAs, using EE 
resource certs (which contain 3779 extensions). This is not a context 
where browsers or other commodity cert processing software will be 
used. I know of at least two independently-developed, open source 
implementations of RP software that deal validate ROAs using resource 
certs. There may be 1 or 2 more implementations in process.  Four of 
the five RIRs have working CA software that issues resource certs, 
and several of them have adopted the offline/online CA model to which 
you refer. So concerns about the difficulty of using X.509 certs here 
seem unfounded.

Given these observations, the public declaration last year by the NRO 
that all 5 RIRs will offer RPKI service as of 1/1/11, and the ongoing 
SIDR WG efforts, most of this discussion seems OBE at this stage.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 18 Mar 2010 14:26:17 -0400

At 2:17 PM -0400 3/18/10, Phillip Hallam-Baker wrote:
>Before declaring victory, lets see if anyone actually uses it to
>validate any data.

fair enough.  anything else is speculation by both of us, so lets 
table the discussion for a year or so.

Steve

---

From: Danny McPherson <[email-masked]>
Date: Thu, 18 Mar 2010 12:36:57 -0600

> > that all 5 RIRs will offer RPKI service as of 1/1/11, and the
> ongoing > SIDR WG efforts, most of this discussion seems OBE at this
> stage. 
Steve,
Thanks for your comments here, not surprisingly, they're spot on...  

Additionally, it might be worth stating that the primary purpose of the 
RPKI and most of the SIDR work to date hasn't been as much about secure
routing as it has been about providing a cryptographically verifiable
authoritative infrastructure describing who holds what number resources
(IPv4, IPv6 and ASNs).  Amazingly, this hasn't existed in any coherent
form until now, and it is necessary before any type of secure routing on
the Internet can happen - it's just that the folks who allocate those
resources haven't had a clear incentive to invest in such an
infrastructure until now.  The best any network operator generating any
type of routing policy derived from allocation information can do today
is hope for Internet Routing Registry (IRR) hooks some Regional Internet
Registries (RIRs) might provide that tie prefix allocations to origin
ASNs (e.g., RIPE's stuff), and hope that those (and all other) IRRs
employ authenticated update mechanisms.  There's very little to no
inter-provider filtering today on the Internet, and it's actually in
worse condition than it was 15 years ago -- while infrastructure
availability is far more critical.  

Enabling secure routing mechanisms, be they in dynamic inter-domain
routing protocols (e.g,. SBGP), computed offline and used for
<prefix,asn(s)> lists or other statically configured routing policy, or
something completely different, is simply one application of an RPKI.
 And certainly, most folks paying attention to this work realize that
you first need a database describing who holds what resources and who is
authorized to originate route announcement associated with a given
resource.  Naturally, alignment of who allocates those resources (e.g.,
IANA->RIRs->...) provides operational simplicity and simplifies
collision avoidance.  Once that exists, you can perform origin
validation, and then look for ways to perform path validation (much more
difficult in practice, but absolutely necessary), and then perhaps
employ that same infrastructure to enable inter-domain feasible path
anti-spoofing techniques.

The statement from the IAB is referring to the global RPKI bits, and at
the end of the day relying parties are going to employ systems and
capabilities such as those being defined in SIDR and enabled by RPKI in
a manner which allows them to comply with corporate or national security
objectives, and discussions that have taken place in that working group
are clearly sensitive to this.  

I'm quite certain that the folks involved with SIDR would welcome any
participation from folks here if you have feasible ideas..

-danny (speaking as an individual)

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Mar 2010 14:31:39 +0900

the draft.

						Masataka Ohta

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 18 Mar 2010 14:17:14 -0400

X.509v3 is a proven technology in the field of authentication.
Attempts to make it do more than authentication do not have a good
record.

If a RIR makes an unintentional error, it will be due to a software
error. That can just as well occur in the X.509 path math as anywhere
else. If the fault is at IANA rather than a RIR, it could cause entire
superblocks of IP address allocations to suddenly be regarded as
bogons.

All that any mechanism can hope to achieve here is to make errors
detectable and possibly correctable. Claiming that one architecture or
another prevents error is bogus.

Let us imagine that an IANA employee manages to corrupt the main data
file so that the superblocks enclosing the A, F and J roots for the
DNS are misallocated. The corresponding IP addresses would suddenly
fall out of the routing tables and the remaining load would probably
overwhelm the remainder in a short time. That would represent the
nearest thing to a 'kill switch' for the Internet.

There are better ways to address the problem than at the RIRs. We
would probably want ISPs to continue to treat the main DNS roots as
special cases when it comes to accepting routing information
regardless of what 'secure' BGP might be telling them. But the idea
that concentrating authority at one node of a system makes things more
stable or more secure is bogus.

On Thu, Mar 18, 2010 at 1:28 PM, Stephen Kent <[email-masked]> wrote:
> I believe that the point the IAB was making is that if each RIR acts as a
> TA, any one of them could make an error (or suffer a compromise) that would
> allow for conflicting certs to be issued below the affected RIR. The certs
> used for the RPKI include RFC 3779 extensions. If IANA acts as the only TA,
> then it will issue certs to the RIRs representing their allocations from
> IANA. Unless IANA makes an error in this cert issuance procedure (which
> should be aligned with its allocation of address space to the RIRs), then
> there can be no (undetected) conflicts among the RIRs re resource holdings.
> Also recall that IANA needs to act as a TA anyway, for unallocated, legacy,
> and reserved address space. So the choice the IAB was addressing was one TA
> vs. six.
>
> You commented that using X.509 certs in this context requires "completely
> new path validation semantics." The semantics are well-defined in RFC 3779,
> which was issued in June 2004. I also observe that OpenSSL already supports
> cert path validation using 3779 extensions, and has done so for at least a
> couple of years. Note also that the RPs here are primarily ISPs. They will
> use software that yields outputs consistent with their goals of origin AS
> validation. Based on the SIDR WG activities, this means validating ROAs,
> using EE resource certs (which contain 3779 extensions). This is not a
> context where browsers or other commodity cert processing software will be
> implementations of RP software that deal validate ROAs using resource certs.
> There may be 1 or 2 more implementations in process.  Four of the five RIRs
> have working CA software that issues resource certs, and several of them
> have adopted the offline/online CA model to which you refer. So concerns
> about the difficulty of using X.509 certs here seem unfounded.
>
> Given these observations, the public declaration last year by the NRO that
> all 5 RIRs will offer RPKI service as of 1/1/11, and the ongoing SIDR WG
> efforts, most of this discussion seems OBE at this stage.
>
> Steve
>

---

From: Danny McPherson <[email-masked]>
Date: Thu, 18 Mar 2010 12:28:10 -0600

Steve,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 18 Mar 2010 15:11:45 -0400

That is what people asked me to do in 2000 with respect to DNSSEC. Ten
years later we are just about to have a Bar BOF (not even a real one)
on how to get end-entity key information into the TLDs.

I don't think anyone would want to make that mistake again.

My approach to solving problems is to anticipate them and seek to
address them before they arrive. What is yours?

On Thu, Mar 18, 2010 at 2:26 PM, Stephen Kent <[email-masked]> wrote:
> fair enough.  anything else is speculation by both of us, so lets table the
> discussion for a year or so.
>
> Steve
>