Subject: [sidr] a hack for the next generation of rpki-based origin validation

From: Randy Bush <[email-masked]>
Date: Thu, 16 Feb 2012 14:23:41 -0800

jay, i sent you this a couple of months back and you said to wait.  but
i hear you have raised it again, so here it is, finally leaving my emacs
edit buffer

randy

---

this is absolutely not for now, but for the next generation of the
protocols once we have some experience under our belts.  i.e. something
to think about to keep you from being bored.

an ops friend said that they have 10.0.0.0/8 with a lot of bgp customers
below it.  it will take a long time to get roas out for those customers.
in the meantime they would like to protect 10.0.0.0/8 and maybe the two
/9s below it.  

i am not sure i really support this idea as it defeats the basic
protections against hole punching which we want.  and it really just
supports the lazy who are unable to simply run code against their
back-end db to gen the roas.  and if they don't have the back-end db,
wuzza wuzza.  but here is a hack which i think could do it.

use max-len==0 to denote marking the exact prefix/len as valid, but not
invalidating covered prefixes from other asns.  i.e. issuing roas for

   10.0.0.0/8-0    42
   10.0.0.0/9-0    42
   10.128.0.0/9-0  42

would cause the marking of the following as valid

   10.0.0.0/8      42
   10.0.0.0/9      42
   10.128.0.0/9    42

and the following as notfound

   10.42.0.0/24    42
   10.42.0.0/16    666
   10.77.0.0/24    666

but would cause the marking of the following as invalid

   10.0.0.0/8      666
   10.0.0.0/9      666
   10.128.0.0/9    666

the friend realizes that 10.x.0.0/10 could be hole-punched to death.  if
he wants to stop that, he should not use max-len==0.

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 16 Feb 2012 14:31:40 -0800

> My feeling now is that I'd rather not see RPKI-related standards
> cluttered with this.  If that means that the 10.0.0.0/8 folks have
> some homework to do prior to publishing a ROA for 10.0.0.0/8 itself,
> then so be it.
> 
> (While this topic did come up just recently in another venue, I have
> not been requesting it or even wishing it were so -- just
> acknowledging that some of us providers will have some work to do.)

i think we are in agreement on this one.  after all, that's why we are
paid the big bucks and pigs fly.

as i said

>> wuzza wuzza.  but here is a hack which i think could do it.

but hax r us, so i did suggest one :)

randy

---

From: Jay Borkenhagen <[email-masked]>
Date: Thu, 16 Feb 2012 17:29:43 -0500

Hi Randy,

Thanks for participating in that discussion with me earlier.

Thanks.

						Jay B.

Randy Bush writes:
 > _______________________________________________
 > sidr mailing list
 > [email-masked]
 > https://www.ietf.org/mailman/listinfo/sidr

-- 
  Jay Borkenhagen     [email-masked]     AT&T Internet Services

---

From: "Murphy, Sandra" <[email-masked]>
Date: Fri, 17 Feb 2012 01:08:06 +0000

Speaking as only a regular ol' member.

btw: I agree with the "this is absolutely not for now" part.

Your idea authorizes one prefix and says "more specifics are OK".  

Synopsis: It doesn't buy you much and it makes life much more complicated.

First, saying "more specifics are OK" does not buy you much protection.

Right now, a hijack of the /8 itself and any more specifics will succeed.  That's 
2*24 possible hijacks.  (Yes, I know the /25-/32 will be rejected many places 
with prefix length limits.)

In a time and place where RPKI was being used in origin validation, if the /8 
does not have a ROA, then a hijack of the /8 itself and any more specifics 
(not covered themselves by ROAs) will be judged UNKNOWN.  That's 
2*24 hijacks (max) looking UNKNOWN.

In a time and place where RPKI was being used in origin validation, if the /8 
does have a "more specifics are OK" ROA, then a hijack of the /8 itself will 
be INVALID and any more specifics (not covered themselves by ROAs) will 
be judged UNKOWN.  That's 1 attack that is INVALID and 2**24-1 attacks 
that are UNKNOWN.

That's a 1/(2**24) improvement in your security.  Not that much help.

Second, life gets a lot more complicated.

NOTE: I am not suggesting opening a discussion of how this idea might be 
improved.  I am pointing to the necessary confusion that results when there 
are contradicting sorts of semantics ("more specifics ARE OK" vs "more 
specifics ARE BAD").

As the /8 ISP starts (or its customers start) to issue ROAs for more specifics, 
it/they will want to issue the strong ROAs, the ones that protect against more 
specific hijacks as well.

If there is a weak ROA for the /8 and a strong ROA for a /16, how do you 
evaluate a route for a /24?  

If there is a strong ROA for the /16, and a weak ROA for a /20, how do you 
evaluate a route for a /24? 

Can you change a weak ROA into a strong ROA?  When can you do that?  
How will the change affect routing elsewhere? Etc.

This complication of validation states was (imho) part of the dissatisfaction 
with the BOA suggestion (BOA is another case of contradicting sematics).  
The wg tussled with that for several meetings in a row and eventually gave 
up the idea.  Been there, done that, burned the t-shirt, etc.

--Sandy, regular ol' member

________________________________________
From: [email-masked] [[email-masked]] on behalf of Randy Bush [[email-masked]]
Sent: Thursday, February 16, 2012 5:23 PM
To: Jay Borkenhagen
Cc: sidr wg list
Subject: [sidr] a hack for the next generation of rpki-based origin     validation

randy

---

   10.0.0.0/8-0    42
   10.0.0.0/9-0    42
   10.128.0.0/9-0  42

   10.0.0.0/8      42
   10.0.0.0/9      42
   10.128.0.0/9    42

   10.42.0.0/24    42
   10.42.0.0/16    666
   10.77.0.0/24    666

   10.0.0.0/8      666
   10.0.0.0/9      666
   10.128.0.0/9    666

randy

---

From: Doug Montgomery <[email-masked]>
Date: Sat, 18 Feb 2012 10:05:34 -0500

While I won't argue for hacking this, I do think there is a simpler
realization.

If you flagged a ROA such that it would not be considered in the search
for a covering ROA unless it exactly matched the length of the announced
prefix (i.e., a "Not aggregate ROA"). That is a simple check on step one
of the validation procedure of RFC6483.

That would leave the more specifics UNKNOWN.

If operative policy is IGNORE INVALID, the stature of the more specifics
is no different than if we had not created the not-aggregate ROA for the
/8.  As ROAs for the more specifics of the /8 are created, they will move
the relevant more specifics from UNKNOW to either VALID or INVALID as the
case may be.

Not sure any of that is worth pursuing, but I do think there is another
realization what is less complex/damaging that what is imagined below.

dougm

---

From: Doug Montgomery <[email-masked]>
Date: Sat, 18 Feb 2012 10:08:44 -0500

Oops ... Sorry, that was Randy's first note/idea ... Somehow that got lost
when I read Sandy's description.

Seems like we have been down this path.

I should catch up from the bottom up of the thread, not top down.

dougm

---

From: Randy Bush <[email-masked]>
Date: Sat, 18 Feb 2012 18:25:48 -0500

> I should catch up from the bottom up of the thread, not top down.

my fault.  jay had asked me a couple of months back.  i composed the
hack, gave to jay and a few others, but did not publish.  so you got
hit by a submarine job.  at least there were no patents :)

randy