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

From: Massimiliano Stucchi <[email-masked]>
Date: Tue, 15 May 2018 09:40:16 +0200

Hi Grow,

me and Job Snijders have recently submitted
draft-ss-grow-rpki-as-cones-00, which discusses AS-Cones, an attempt to
bring as-sets into RPKI to facilitate route filtering.

We are going to present the this work at the routing working group
meeting during RIPE76 later this week, but we would like to invite
people to read the draft and comment here.

Thanks!

-- 

Massimiliano Stucchi
MS16801-RIPE

---

From: Job Snijders <[email-masked]>
Date: Tue, 15 May 2018 07:52:09 +0000

On Tue, May 15, 2018 at 09:40:16AM +0200, Massimiliano Stucchi wrote:
> draft-ss-grow-rpki-as-cones-00, which discusses AS-Cones, an attempt
> to bring as-sets into RPKI to facilitate route filtering.
> 

We'd especially love help from people who have experience defining
profiles for RPKI signed objects! ASN.1 is not my strong suit :-)

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Sun, 20 May 2018 14:41:06 +0200

Hi Chris, WG,

I’d like to ask for a call for working group adoption for this document. At
the RIPE 76 Routing Working Group session there seemed to be interest in
this topic.

Kind regards,

Job

---

From: Gert Doering <[email-masked]>
Date: Mon, 21 May 2018 13:28:49 +0200

Hi,

On Sun, May 20, 2018 at 02:41:06PM +0200, Job Snijders wrote:
> I???d like to ask for a call for working group adoption for this document. At

I'm far from understanding all the potential implications, but for the
usage scenario "I want to use RPKI to build IRR-like filters towards
my customers' BGP sessions" this seems to provide me the tools.

As in:

  - query customer policy object for as-cone
  - (recursively) gather ASes from as-cone object(s)
  - query AS policy objects to see whether the announcement is supposed
    to travel towards $customer->$me at all
  - build filter that is much more precise than "grab AS-Set from IRRDB
    which can contain anything"

(yes, the AS-Cone can also "contain anything", so it needs to go hand in 
hand with the policy object to be more useful than the AS-Set RPSL object)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 21 May 2018 11:04:57 -0400

It seems reasonable to ask for adoption... I'll send a note forthwith
requesting input on same!

> I’d like to ask for a call for working group adoption for this document.
At the RIPE 76 Routing Working Group session there seemed to be interest in
this topic.

---

From: Randy Bush <[email-masked]>
Date: Mon, 21 May 2018 13:02:24 -0700

> bring as-sets into RPKI to facilitate route filtering.

in irr, an as-set may reference an as-set.  could you explain the
authority model you have for this when as-sets are signed?

randy

---

From: Job Snijders <[email-masked]>
Date: Wed, 23 May 2018 15:48:49 +0200

Dear Randy,

> authority model you have for this when as-sets are signed?

My initial thinking for RPKI AS Cones, is that a given Cone in an ASN's
namespace can only be defined by the owner of the ASN in who's namespace
the Cone is defined. If a reference is included to another Cone residing
in someone elses namespace, a provisioning system can follow the
reference and verify that the referenced Cone is defined by the ASN
who's namespace that cone resides in.

AS Cone Certificates are EE Certificates. 

The draft needs a ton of work to properly communicate to implementers
what goes where. I am a novice when it comes to the X.509 / PKIX /
ASN.1.

Kind regards,

Job

---

From: Randy Bush <[email-masked]>
Date: Wed, 23 May 2018 08:03:45 -0700

> My initial thinking for RPKI AS Cones, is that a given Cone in an
> ASN's namespace can only be defined by the owner of the ASN in who's
> namespace the Cone is defined.

namespace?  isn't this the irr authorisation model?  and how did that
work out for us?

> what goes where.

it would benefit from a bit of work on the authority and attestation
model first.

randy

---

From: Job Snijders <[email-masked]>
Date: Wed, 23 May 2018 17:07:28 +0000

On Wed, May 23, 2018 at 08:03:45AM -0700, Randy Bush wrote:
> >>> draft-ss-grow-rpki-as-cones-00, which discusses AS-Cones, an
> >>> attempt to bring as-sets into RPKI to facilitate route filtering.
> >> 
> namespace?

In the IRR world we have the concept of hierarchical naming of AS-SETs:
an example is "AS15562:AS-SNIJDERS" [1] - under the "AS15562" hierarchy
only the owner (or delegated folks) can add/change/remove AS-SETS. I
call this a namespace, should a different term be used?

> isn't this the irr authorisation model?

The IRR AS-SET feature is working pretty well (since it is better than
nothing), but there are some downsides.

For instance "AS15562:AS-SNIJDERS" can exist in multiple IRR databases,
and we don't know which of those was actually created by the owner of
AS15562. I hope this can be addressed in AS Cones.

Another problem is that there no longer is a way (or perhaps there never
was) to autodetect what AS-SET should be used by which organisation to
generate a filter. RPSL is broken, fundamentally flawed. Perhaps this
can be addressed - not by introducing a new language - but just having a
handy naming convention. Think of it as "AS15562:AS-2914", so AS 2914
knows it should use AS15562:AS-2914 if it exists, and if it doesn't
exist use AS15562:AS-DEFAULT.

> and how did that work out for us?

I consider it a feature that anyone can add anything to an AS-SET they
created, this puts the workload on transit providers and doesn't require
stub networks to do anything. The "member-of:" feature is barely used
and seems to pose too much work.

Clock is ticking... multiple RIRs are struggling with their IRRs (or
lack thereof). If IETF does not pony up a solution that is good enough
for operational purposes, we may end up with RIRs investing in legacy
technology and a continuation of the duplication/discovery/ownership
issue. There is an opportunity here and now, let's work on it?

Kind regards,

Job

[1]: https://apps.db.ripe.net/db-web-ui/#/query?searchtext=AS15562:AS-SNIJDERS#resultsSection

---

From: Brian Dickson <[email-masked]>
Date: Wed, 23 May 2018 10:24:57 -0700

Sorry for the top-reply:

I think the fundamental problem with AS-SETs in IRR is the unilateral
aspect of "control" of what amounts to assertion of a relationship.

Given the basic mechanisms already in play for RPKI (keys, signing, etc.),
I think this would be easy enough to fix:

   - Any relationship asserted should require both parties to confirm by
   signing
   - Any relationship can be revoked by either party (thus fixing the main
   IRR problem)
   - Anyone else can confirm that relationship via signatures
   - The nature of the relationship would need to be reflected, in order to
   have maximum benefit. E.g. transit-provider, transit-customer, peer,
   mutual-transit, other.
   - This plays well with preventing route-leaks, too.

This would only require the ability to associate things like groups of ASNs
with single entities that speak for them. If that isn't already part of
RPKI, it would need to be added.

Brian

On Wed, May 23, 2018 at 10:07 AM, Job Snijders <[email-masked]> wrote:

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

---

From: Job Snijders <[email-masked]>
Date: Wed, 23 May 2018 19:46:15 +0200

> aspect of "control" of what amounts to assertion of a relationship.

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).

What you describe is quite low on the wish list from my perspective. Are
you using as-sets for filter generation today?

Job

---

From: Jared Mauch <[email-masked]>
Date: Wed, 23 May 2018 13:48:26 -0400

> On May 23, 2018, at 1:24 PM, Brian Dickson <[email-masked]> wrote:
> 
> Sorry for the top-reply:
> 
> I think the fundamental problem with AS-SETs in IRR is the unilateral aspect of "control" of what amounts to assertion of a relationship.
> 
> Given the basic mechanisms already in play for RPKI (keys, signing, etc.), I think this would be easy enough to fix:
> 	• Any relationship asserted should require both parties to confirm by signing
> 	• Any relationship can be revoked by either party (thus fixing the main IRR problem)
> 	• Anyone else can confirm that relationship via signatures
> 	• The nature of the relationship would need to be reflected, in order to have maximum benefit. E.g. transit-provider, transit-customer, peer, mutual-transit, other.

So, this poses some challenges as it won’t actually fit into a well defined set of use-cases.

Being able to specify who can announce my route (or routes) and giving them a good way to specify this cone seems helpful.  Requiring both parties to sign, countersign, etc.. is not desirable or is problematic operationally.  How many e-mails back and forth have you seen go by where getting this updated is a problem?  I’ve seen quite a bit.  Not everyone is well automated and trying to use this as a sledge to turn that screw is going to be met with a collective yawn and be ignored by many folks.

- Jared

> 	• This plays well with preventing route-leaks, too.
> This would only require the ability to associate things like groups of ASNs with single entities that speak for them. If that isn't already part of RPKI, it would need to be added.
> 
> Brian
>

---

From: "Randy Bush" <[email-masked]>
Date: Wed, 23 May 2018 11:21:07 -0700

> 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.

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)?

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?

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.  but *anyone* can put 
an arbitrary AS number in an asID.

i keep following the heffalump tracks around this tree, but am becoming 
more and more confused.

randy

---

From: Job Snijders <[email-masked]>
Date: Wed, 23 May 2018 19:33:07 +0000

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).
> 

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’
> 
> 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

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 23 May 2018 16:22:06 -0400

<lurk mode=off>

> resolve various issues, such as "does AS-STEALTH belong to AS41847 or to
wait, they signed this data and put it in their RPKI publication point (for
instance - forget that there is no RPKI object type for this), so they
'claimed':
  as-set:     AS-STEALTH

from which IRR? Or did you mean that they may sign something like:
  as-set:     AS-STEALTH@radb

but did not sign:
  as-set:         AS-STEALTH@RIPE

Else we still have confusion, because the MAINT-AS8002 may be upset when I
only accept AS-SET content from STEALTH-NET-MNT :(

-chris
(who hopes to one day have better answers for this than: "err, ask the
customer / peer which irr they use?"

---

From: Job Snijders <[email-masked]>
Date: Wed, 23 May 2018 20:26:25 +0000

On Wed, May 23, 2018 at 04:22:06PM -0400, Christopher Morrow wrote:
> > 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"?
>
> wait, they signed this data and put it in their RPKI publication point
> (for instance - forget that there is no RPKI object type for this), so
> they 'claimed':
>   as-set:     AS-STEALTH
> 

You are now describing issues of the IRR, I merely used this example to
illustrate the problem. With AS Cones we can do better. We can structure
the naming convention for this type of objects.

For instance, for an AS Cone named "AS15562:AS-SNIJDERS" - we can
structure it in such a way that only the CA Holder of the cert related
to AS 15562 can sign "AS15562:AS-SNIJDERS". Earlier in the thread I used
the term 'namespace'.

Kind regards,

Job

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 23 May 2018 21:36:21 +0100

> customer / peer which irr they use?"

congrats, you just stood on the trust model dog turd.

Right now we have the lolz model (anyone can put anything in any 
non-authoritative IRR and it will be accepted) and the top-down model 
(only legitimate holders can insert data into authoritative IRRs - 
applicable to rpki, apnic irr, arin-whois and soon ripe-irr).

If you want better answers than "ask the customer", you'll need to solve 
this problem.

If you mention blockchain, I will slap you.

Nick

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 23 May 2018 16:56:56 -0400

> the naming convention for this type of objects.
ok, cool.

> to AS 15562 can sign "AS15562:AS-SNIJDERS". Earlier in the thread I used
ok, my misunderstanding perhaps :) Oh, so: "like as-set, not as-set
exactly".

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 23 May 2018 16:58:31 -0400

> congrats, you just stood on the trust model dog turd.
now I need new shoes :(

> applicable to rpki, apnic irr, arin-whois and soon ripe-irr).
right... this makes discussions of route filtering "hard" because: "but the
data quality!!" :(

> If you want better answers than "ask the customer", you'll need to solve
excellent. RPKI?

> If you mention blockchain, I will slap you.
I was thinking we could chain netblocks with certs, call it:
"netBlockChain" ?

---

From: Job Snijders <[email-masked]>
Date: Wed, 23 May 2018 21:07:28 +0000

> ok, my misunderstanding perhaps :) Oh, so: "like as-set, not as-set

yes, "as-sets in rpki", but we didn't want to call it "as-sets" because
there already is IRR AS-SET and BGP AS_SET - so "AS Cones" was coined.

Kind regards,

Job

---

From: Brian Dickson <[email-masked]>
Date: Wed, 23 May 2018 16:40:59 -0700

> you using as-sets for filter generation today?

So, the question about what I do, is irrelevant (bordering on ad-hominem).
The relevant questions, IMHO, are:

   - Is anyone using as-sets for filter generation?
   - Are there limitations on the semantics of as-sets, that prevent the
   generation of filters that can stop all classes of route-leaks?
   - Are there ways to fix this, if we go down the RPKI path?

The answers are "yes", "yes", and IMHO, "yes". While they might not be high
on your list, the solution is relatively easy to define and implement, and
to do so in a way that won't block the things you propose already.

It's an addition, optional but recommended, with slightly stronger controls
and semantics.

The "cone" draft allows an AS to assert the "customer-of" relationship to
its transit provider(s).
That's good, and prevents many kinds of route-leaks (presuming
registrations are done and filters built, etc.)
E.g.: leaf AS leaking full tables upstream would be blocked (if transit
providers filter their customers); peer-peer-peer leakage would be blocked
(if peers filter); peer-peer-transit would be blocked (if transit providers
filter their customers).
All of those are where only customer routes should be announced (to
upstreams or peers), limiting the announcements to the "cone".

(Aside: everyone is also building as-path filters from this data too,
right? Because without that, as-path shortening can be done...)

There is one category of leaks, or leak-like attacks, that won't be
prevented using the transit cone, which is what I'm suggesting adding: the
explicit peering sets (for validating the as-paths received from transit
providers).

There currently is no mechanism to detect (or prevent) anyone from claiming
a particular peering (or transit) relationship with any other AS, to their
customers.

Adding explicit peering declarations would enable that, and facilitate
blocking improper announcements by transit providers.

I don't want to give particular named examples, but I believe this is a
problem in places with authoritarian regimes and mandated transit
providers. Anyone peering with such entities, or getting transit from them,
may end up sending traffic over a path that would be ill-advised, if they
were aware of the as-path manipulation.

It is an (extreme) corner case, but I think this is the place to address it
with technology.

By all means, this should not block the primary stuff (unilateral
parent-identification with signatures).

Brian

P.S. I was wrong about the bilateral signing being needed for the transit
path stuff, please forgive that oversight.