Subject: [sidr] Two important points

From: Sandra Murphy <[email-masked]>
Date: Tue, 25 Nov 2008 16:12:49 -0500 (Eastern Standard Time)

I've seen two points in this latest discussion that I think are important 
(both brought up by Geoff in some of his messages).  I'd like the wg to 
keep them in mind when analyzing validation.

First is the thorny issue of incremental deployment.  As ISPs begin to use 
this work, we will undoubtedly have cases such as:

   ATT understand the RPKI and uses certs and ROAs, but their multihomed
   customer in Bolivia, to whom they have sub-allocated some of their
   space, does not.  Just exactly what can ATT do (what gets signed by
   whom and what gets checked by whom) that will prevent a more-specific
   prefix hijacking but will not dis-enfranchize their legitimate but
   clueless customer?

   An RIR has been delegation 64/8.  Just exactly how (what gets signed by
   whom and what gets checked by whom) do we prevent annoucements of
   superblocks of and within this delegation?

We must know exactly how to validate routes with RPKI material, so we must 
settle this.

Second is the exact semantics of the ROA itself or a set of ROAs. 
It is clear that everyone is not reading from the same page for this
(which is troubling to show up this late in the specification game).
This has shown up in several messages, and the popular alternatives are
    a set of ROAs grants right to use a prefix to a set of ASs
    a set of ROAs grants right to use a prefix to a set of ASs and no
         others.

Knowing how to validate BGP route advertisements depends completely on
the semantics of a ROA, so we must settle this also.

Proponents of a solution to the first set of problems should be clear 
about what semantics they are using.  Opponents of a solution to the first 
set of problems should be clear about what semantics they are assuming are 
to be used.  Proponents and opponents of one of the semantics should be 
clear about what solution they see that is supported by the semantics they 
choose.

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

---

From: Randy Bush <[email-masked]>
Date: Wed, 26 Nov 2008 22:10:04 +0900

>   prefix hijacking but will not dis-enfranchize their legitimate but

AT&T owns the prefix.  they are responsible for the routing.  they issue
  o a ROA for the whole prefix to their own ASN with max-len as they
    announce it
  o a ROA for the sub-alloc to customer's ASN with max-len that AT&T is
    willing to get whines for routing table pollution

>   superblocks of and within this delegation?

the rir has no authority to prevent anything of the superblock, e.g.
64/7, because 65/8 is not theirs to control.

blocks within 64/8 will be ROAed by the folk to whom the rir allocates.

blocks within 64/8 which have not been allocated may be announced by
anyone, and there is no roa to contradict them.

the rir should not issue a roa for 64/8-8 to itself because then they
would have to become involved in issuing ROAs for the allocatees which
are not capable of issuing ROAs themselves.

yes, during roll-out, the spammers can still source from unused rir
space, though not unused iana space, as iana can blackhole ROA the whole
/8.  but the primary goal is to secure correct routing, not to prevent
spam.

> Second is the exact semantics of the ROA itself or a set of ROAs. It is
> clear that everyone is not reading from the same page for this

as i said in a previous message, imiho the latter.

note that, in the first section, if the rir was to issue
    64/8-8 A(rir)
and an allocatee issues
    64.42/24-24 A(allocatee)
the router has to recognize that the latter means accept an announcement
of 64.42/24 from A(allocatee) despite the mismatch to 64/8-8 A(rir).

but, as i said above, i do not advise the rir to issue the 64/8-8
A(rir).  they are the only ones in the chain, iana, rir, nir, lir, lir,
user, which is ill advised to do so.

randy