Subject: [sidr] is a longer announce invalid or not found?

From: Randy Bush <[email-masked]>
Date: Fri, 30 Sep 2011 11:39:21 +0900

there has been a bit of confusion over whether announcement of a longer
prefix than is covered by a roa is valid, invalid, or not found.  so let
me try to clarify the underlying decision process for valid, invalid,
and not found so we are all on the same page.  i believe this is as it
is documented in pfx-validate.

---

if i publish a roa for 10.0.0.0/16-16 for AS 42 (and there are no other
roas for 10/...)

no announcement of 10.0.0.0/16 or any longer prefix thereof from any AS
may be marked NOT FOUND, after all, a covering roa is there.

any announcement of any prefixes in that space, from /16 to /32, from an
AS other than 42 are INVALID.  this is the purpose of the exercise.

and, an announcement of 10.0.666.0/24 from AS 42 is INVALID, as it has a
prefix length not specified by the roa.  someone is trying to punch a
hole, not allowed.  this could be an origin forger trying to punch a /24
in my /16.

but if i publish a roa for 10.0.0.0/16-24 for AS 42, then an
announcement for 10.0.666.0/24 from AS 42, would be marked VALID.

randy

---

From: Pradosh Mohapatra <[email-masked]>
Date: Thu, 29 Sep 2011 20:21:11 -0700

> is documented in pfx-validate.

I concur.

From a partial deployment perspective, it does mean that once a ROA is 
published for an address block (and follows the ops guideline of being precise), 
further sub-allocations NEED to have the ROA published. Otherwise, they
would be marked invalid and risk being not routed.

- Pradosh

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

---

From: Randy Bush <[email-masked]>
Date: Fri, 30 Sep 2011 12:22:22 +0900

> published for an address block (and follows the ops guideline of being
> precise), further sub-allocations NEED to have the ROA
> published. Otherwise, they would be marked invalid and risk being not
> routed.

from draft-ietf-sidr-origin-ops-10

   Before issuing a ROA for a super-block, an operator MUST ensure that
   any sub-allocations from that block which are announced by other ASs,
   e.g. customers, have correct ROAs in the RPKI.  Otherwise, issuing a
   ROA for the super-block will cause the announcements of sub-
   allocations with no ROAs to be viewed as Invalid, see
   [I-D.ietf-sidr-pfx-validate].

randy

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 30 Sep 2011 09:59:54 +0200

Let me clarify one nit ...

In the other mail you said:

"any announcement of any prefixes in that space, from /16 to /32, from 
an AS other than 42 are INVALID."

In the light of the below quote from origin-ops-10 should the above be 
reworded as:

"any announcement of any prefixes in that space, from /16 to /32, from 
an AS other than 42 are INVALID unless a valid ROA is present in the 
RPKI covering such sub-allocation"

Thx,
R.

---

From: Randy Bush <[email-masked]>
Date: Fri, 30 Sep 2011 17:03:09 +0900

> RPKI covering such sub-allocation"

perhaps you missed the start of the discussion

>> if i publish a roa for 10.0.0.0/16-16 for AS 42 (and there are no
>> other roas for 10/...)

randy

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 30 Sep 2011 12:17:55 +0200

On Fri, Sep 30, 2011 at 11:39:21AM +0900, Randy Bush wrote:
| if i publish a roa for 10.0.0.0/16-16 for AS 42 (and there are no other
| roas for 10/...)
| 
| no announcement of 10.0.0.0/16 or any longer prefix thereof from any AS
| may be marked NOT FOUND, after all, a covering roa is there.
| 
| any announcement of any prefixes in that space, from /16 to /32, from an
| AS other than 42 are INVALID.  this is the purpose of the exercise.

i have a question then:
what is the conceptual difference between
10.0.0.0/16-16 and 10.0.0.0/16-32
following the logic above ?

my read of 10.0.0.0/16-16 is an exact match
and 10.0.0.0/16-32 is a subtree match ('orlonger' in JUNOS policy terms ;-))

---

From: Randy Bush <[email-masked]>
Date: Fri, 30 Sep 2011 19:34:26 +0900

> and 10.0.0.0/16-32 is a subtree match ('orlonger' in JUNOS policy

yes.

fwiw, i do not remember junos as having a policy term to express
10.0.0.0/16-14  :)

randy

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 30 Sep 2011 14:28:33 +0200

On Fri, Sep 30, 2011 at 07:34:26PM +0900, Randy Bush wrote:
| > my read of 10.0.0.0/16-16 is an exact match
| > and 10.0.0.0/16-32 is a subtree match ('orlonger' in JUNOS policy
| > terms ;-))
| 
| yes.

so why is it (per your previous example) 'invalid' then -
since a exact match was requested and no exact match could be found
it should be 'not found'. - if one wanted to match against the whole
subtree then 10.0.0.0/16-32 shall be advertised and signed;

| fwiw, i do not remember junos as having a policy term to express
| 10.0.0.0/16-14  :)

have a look at 'prefix-length-range' policy qualifier.
http://www.juniper.net/techpubs/software/junos/junos94/swconfig-policy/defining-route-lists.html
e.g. route-filter 10.0.0.0/14 prefix-length-range /14-/16

---

From: Randy Bush <[email-masked]>
Date: Fri, 30 Sep 2011 23:35:18 +0900

> it should be 'not found'.

because we call it an attack.  see all the specs.

> if one wanted to match against the whole subtree then 10.0.0.0/16-32
> shall be advertised and signed;

almost the opposite.

> e.g. route-filter 10.0.0.0/14 prefix-length-range /14-/16

cool

randy

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 30 Sep 2011 12:09:58 -0400

An attacker could announce 10.0.0.0/17 and 10.0.128.0/17.
This is equivalent to announcing 10.0.0.0/16, so it must be INVALID.

10.0.0.0/16-16 means I can announce 10.0.0.0/16, but not 10.0.66.0/24. I would do this if I have sub-allocated 10.0.66.0/24 to my customer. My customer MUST publish an ROA for 10.0.66.0/24.

If my customer does not support SIDR, then I MUST revoke my ROA for 10.0.0.0/16-16 and replace it with ROAs for
10.0.0.0/18-18
10.0.64.0/23-23
10.0.67.0/24-24
10.0.68.0/22-22
10.0.72.0/21-21
10.0.80.0/20-20
10.0.96.0/19-19
10.0.128.0/17-17

As I sub-allocate more, I must split it more.
However, I could sub-allocate 10.0.666.0/24 to Randy and need split nothing :)

--
Jakob Heitz.

---

From: Randy Bush <[email-masked]>
Date: Sat, 01 Oct 2011 05:23:54 +0900

> If my customer does not support SIDR

then create the subsidiary cert, ee cert, and roa for them.  you will
then have two certs,
  10.0.0.0/16-16
  10.0.66.0/24-24

i call this the lazy customer.  they probably pay me to one or more of
provision the circuit, configure their cpe, ...  i might as well
provision their certs and roa.

randy

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 30 Sep 2011 16:32:20 -0400

> then create the subsidiary cert, ee cert, and roa for them.  you will

Will you sign his announcement too?
If he doesn't implement sidr on all his routers yet,
he will not sign his announcements.

-- 
Jakob Heitz.

---

From: Randy Bush <[email-masked]>
Date: Sat, 01 Oct 2011 05:40:53 +0900

> Will you sign his announcement too?

no, because we are talking origin validation, not bgpsec

> If he doesn't implement sidr on all his routers yet, he will not sign
> his announcements.

first, 'sidr' is highly ambiguous.  sidr is documenting three main
technologies, rpki, rpki-based origin validation, and bgpsec.  we were
discussing the first two.

second, origin validation and bgpsec can be partially deployed within an
operator.  this is one of the reasons they are blended into local
policy, and do not force policy upon the operator.

third, a (let's assume dual homed) leaf site does not have to do much
for bgpsec.  their upstreams validate, so they do not have to.  all they
have to do is sign their announcement.  we refer to this as a 'simplex'
site, they announce signed but do not accept signed data, do not hold
any key or cert other than their own, ...  cool result is that current
leaf site hardware could do this, no upgrade.  so, for my simplex lazy
customer, yes i gen the bgpsec router key for them, and they or i stuff
it in their router.

randy

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 30 Sep 2011 16:41:31 -0400 (Eastern Daylight Time)

Speaking as regular ol' member

> he will not sign his announcements.

In origin authorization phase, no signing of announcements is done.

In path validation phase (bgpsec), you are creating his ROAs - so make 
yourself the valid origin - and then yes, sign the originating (your) 
announcement.  Or if you create the cert, then you hold the key, so yes, 
you could sign his announcement.  (Holding the keys gives you ultimate 
power.)

--Sandy, speaking as regular ol' member

---

From: Randy Bush <[email-masked]>
Date: Sat, 01 Oct 2011 05:49:31 +0900

> a (let's assume dual homed) leaf site does not have to do much for
> bgpsec.  their upstreams validate, so they do not have to.  all they
> have to do is sign their announcement.  we refer to this as a
> 'simplex' site, they announce signed but do not accept signed data, do
> not hold any key or cert other than their own, ...  cool result is
> that current leaf site hardware could do this, no upgrade.  so, for my
> simplex lazy customer, yes i gen the bgpsec router key for them, and
> they or i stuff it in their router.

< side discussion >

cool hack 14.3: the router itself can gen the public/private key pair a
la ssh, the person configuring can extract the public key and send it to
the rpki goddesses to be signed by the appropriate cert and put in the
rpki.  the private key never leaves the router!

randy

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 30 Sep 2011 16:56:01 -0400 (Eastern Daylight Time)

> rpki.  the private key never leaves the router!

I believe that Steve Kent says that usually a certificate request is 
required to present Proof Of Possession (of the private key).  So just 
discovering the public key somehow would not be sufficient to be able to 
request a cert with that public key.

I await correction in quoting Steve.

---

From: Randy Bush <[email-masked]>
Date: Sat, 01 Oct 2011 05:59:15 +0900

>> cool hack 14.3: the router itself can gen the public/private key pair
>> a la ssh, the person configuring can extract the public key and send
>> it to the rpki goddesses to be signed by the appropriate cert and put
>> in the rpki.  the private key never leaves the router!
> discovering the public key somehow would not be sufficient to be able
> to request a cert with that public key.

dear dr nit pick,

when dealing with goddesses, one always frames things as a request

randy