Re: [GROW] draft-ss-grow-rpki-as-cones-00

[Job Snijders <[e-mail]>]

On Wed, May 23, 2018 at 11:21:07AM -0700, Randy Bush wrote:
> > I believe the fundamental problem is (1) the same AS-SET name can
> > exist in multiple databases (duplication), (2) you don’t know which
> > as-set belongs to which ASN (ownership), and which as-set to use
> > (discovery).
> 
> i think these may be part of the same confuddle; what is the
> “identity” of an as-set?  in the irr, it is the maintainer (even
> ignoring multiple irr bases); but we have no such concept in the rpki.

Actually I thought we do: IANA issues a Certification Authority (CA)
certificate to each Regional Internet Registry (RIR). The RIR in turn
issues a CA certificate to an Internet Service Provider (ISP). The ISP
in turn issues EE certificates to itself to enable verification of
signatures on RPKI signed objects. This last CA is what I'd map to the
'irr maintainer' of an AS-SET.

> my understanding is that an as-set is a short-hand name for a
> collection of names of ASs and the names of other as-sets. when you
> ask that an AS owner sign an as-set, you are making an assertion of
> ownership/scope that i am not sure i understand. the signing AS is
> saying that the nickname is a valid list in some sense (part of
> brian’s question)?

The signing AS is saying they created (and named) the list. This helps
resolve various issues, such as "does AS-STEALTH belong to AS41847 or to
AS8002"? 

> as the old rpki joke goes, you can use your cert to sign a gif of
> naked furries or a bank transaction.  but what is the security
> *meaning* of your doing so?

The signing AS is saying they created (and named) the list, this in
itself is incredibly helpful.

> from the draft:
> > to enable operators to define a set of customers that can be found
> > as "right adjacencies", or transit customer networks, facilitating
> > the construction of prefix filters for a given ASN’
> 
> so, when AS42 signs a list {AS1, AS2}, is AS42 trying to say that
> someone peering with AS42 should expect any prefixes for which there
> are ROAs with AS42, AS1, or AS2 in the ROA’s asID.

When AS 42 signs a list {AS 1, AS 2} and names the list "AS42-AS2914"
(or whatever convention / discovery mechanism we settle on) - AS2914
knows that it can create a prefix-list by doing inverse lookups for AS1,
AS2 (and perhaps AS 42 itself). AS 2914 knows at that point that AS 42
created the list. This information can be used to provision sessions
between 2914 and 42.

> but *anyone* can put an arbitrary AS number in an asID.

So? Same goes for IRR route-objects.

A second use case for the list is generation of AS_PATH filters.

Kind regards,

job