Subject: Re: [sidr] Prefix-Origin Validation Use Cases

From: "Larry J. Blunk" <[email-masked]>
Date: Sat, 20 Mar 2010 10:05:35 -0400 (EDT)

----- "Randy Bush" <[email-masked]> wrote:

> max-len is at the choice of the issuer of the roa.  it is a macro so
> they do not have to issue all the smaller roas.  if they don't want the
> longer prefixes announced, then they should not issue the roas, whether
> as individual roas or in the equivalent max-len macro.

    Randy, my point is that one should be careful in the
use of maxlen.   If you do not intend to actually announce
the more specifics on a continuous basis, or only intend
to announce a subset of the more specifics, you are opening
yourself up to an attack from someone who
announces the currently unannounced more specifics (and
inserts the correct origin in the path to pass the origin
check).

> 
> and the pakistan telkom accident is not a useful analogy.  the
> announcement did not come from the owning asn.
> 

   The lesson was about the danger of more specifics.
Would the attack had been as successful if had
announced a matching /22 instead of a /24?  Imagine
a ROA future where Pakistan Telkom replays the attack
and inserts the correct origin in the path to match the
Youtube ROA.   The attack still succeeds if Youtube
has a maxlength of 24 for their /22 ROA.   It fails if
Youtube requires an exact match 22 in their ROA.

   I would also point out that the AS7007 incident involved
more specifics, not just exact match prefix lengths.
ROA's give one the ability to specify both origin AS
and prefix length.  Gratuitous use of maxlength
negates the prefix length matching capability of ROA's.

 -Larry

---

From: Randy Bush <[email-masked]>
Date: Sat, 20 Mar 2010 09:43:54 -0700

> negates the prefix length matching capability of ROA's.

your use of the word attack is not appropriate.  it was an accident.

aside from that, all of this is true.  roas simply can not and will not
deal with deliberate forging.  they do not deal with attacks.  they
just deal with 99% of the problems we have today, fat fingered
accidents.  a roa for the /22, with or without roas for the covered
/24s would have prevented the pt accident.

dealing with attacks is a non-trivial design and engineering problem.
if you want to know how hard, i suggest looking at sharon goldberg's
work in this area.

<rant>

where roas will fail in even their simple task is more likely roa and
certificate expiration and/or invalidation.  with some rirs planning on
turning certificate and roa issuance into an income stream tied to
leasing the address space which they got for free [0], any use of the
rpki approach to make routing more resilient is doomed.

randy

---

[0] - remember all the rir assertions that the rirs abjure all control
      of routing?  well, this is a horrifyingly strong control.