Subject: [GROW] WG ADOPTION - draft-ss-grow-rpki-as-cone - ENDS: June 04, 2018

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

howdy GROW-WG denizens,
please have a read through:
   https://datatracker.ietf.org/doc/draft-ss-grow-rpki-as-cones/

Abstract:
   "This document describes a way to define groups of Autonomous System
    numbers in RPKI [RFC6480].  We call them AS-Cones.  AS-Cones provide
    a mechanism to be used by operators for filtering BGP-4 [RFC4271]
    announcements."

and discuss applicability to the GROW-WG, and whether or not this document
is a work item we'd like to pick up and march forward.

thanks!
-chris
co-chair

ps: job sort of did ask this same question... so either on this thread or
the original:
   Subject: [GROW] draft-ss-grow-rpki-as-cones-00
is a fine place to comment.

---

From: Danny McPherson <[email-masked]>
Date: Mon, 21 May 2018 15:17:34 -0400

I've read the I-D, I support the idea, given that the inverse (validated 
IRR-derived/RPSL from RPKI) is more problematic.  I suspect this may be 
a slippery slope into reconstituting IRRs in RPKI but if I must be stuck 
with RPKI why not...

-danny

On 2018-05-21 11:08 AM, Christopher Morrow wrote:
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Fri, 25 May 2018 14:56:26 +0000

Chris,

I have read the document and feel that the work is worth pursuing in the WG. Support adoption. 
Willing to contribute and review going forward. 
For now, I have some comments for the authors below. 

Dear authors:

Some of my questions/suggestions may be better handled with a face-to-face 
conversation possibly in Montreal.

1. FWIW, there is precedence regarding the idea of generating prefix filters 
based on RPKI/ROA information; see Appendix C in
https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-08  .
There, we also speculated on different ways of obtaining the AS cone.

A somewhat related idea of an extended ROA was discussed during BGPsec design; 
see list item #3 in Section 6.5.2 of RFC 8374 - https://tools.ietf.org/html/rfc8374 .
The idea was that the stub AS's (who is also owner of prefix(es)) upstream AS 
is also included in the extended ROA in addition to the stub AS.   
It was not pursued because at that time there was reluctance to add more RPKI objects.

I feel it is worth exploring freshly the idea of a signed object that includes
P2C peering info so customer AS cones can be constructed.

2.  I would prefer that the proposed new RPKI objects contain only a list of immediate customers.
>From that (assuming mature state of deployment), the entire customer AS cone for
any AS can be constructed (recursively). 
I see a major down side to including more than the list of immediate customers.
The downside is that there could be too much churn in the RPKI.
If a customer drops or changes a transit provider, then there should not be any ripple effects
in the RPKI propagating through all higher tiers.  I think this rippling effect is inherent
with the current proposal in the draft (as I understand it). 

3. The draft currently does not mention anywhere (based on my one read through)
that AS cert is used to sign the AS cone object. I think an EE cert will be created
from the AS cert and the EE cert will be used to sign the new RPKI object in question
(similar to how ROAs are signed).

4. Consideration needs to be given to special cases, e.g., what happens if 
a neighbor AS is a customer in one region and a peer in another region (hybrid relations).

5. The draft seems to say "network" in some places where "AS" is meant.
Prefixes are normally referred to as "networks" or subnets.

Sriram

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 28 May 2018 15:02:14 +0200

Hi all,

Support adoption. I am willing to contribute ‘RPKI Signed Object’ and ASN.1 text - when the time comes and if desired.

In relation to Sriram’s remark:

> On 25 May 2018, at 16:56, Sriram, Kotikalapudi (Fed) <[email-masked]> wrote:
> 

Quick grepping in the RIPE Database IRR shows that about 15% of “members:” attributes in AS-SET objects references other AS-SET objects. This could be other people’s customers, or it could be shorthands (allowing easy re-use of a set of ASNs in different places). When it’s other people’s customers then it’s not clear to me whether the ASN that makes this reference would still appear in the PATH. In other words, could one not just stick to referencing ASNs only and recursively find the published ‘rpki-as-cone' for those ASNs?

If only ASNs are used, I do believe that the object can be simplified and it would be much easier to reason about who signs what. There could be a single object per AS:

Policy for AS-A

To-upsteam: AS-X, send customers: AS1,2,3
To-upsteam: AS-Y, send customers: AS 4, 5
To-upsteam: AS-Z, send customers: none

Signed AS-A (must appear on EE certificate in the RPKI Signed Object that contains this)

And AS 1,2,3,4,5 would each have their own rpki-as-cone object.

Unless I am missing something here (and please enlighten me if so), I think this would allow for building recursive lists of ASNs that may be seen on a session with a downstream AS, and ROAs and/or IRR objects could be used then to get the filterlists. At least that’s how I understand AS-SET objects to be used today (again, enlighten me if not.. still learning about hands-on operations).

These objects could also be leveraged through a future rkpi-rtr extension and allow for: valid/invalid/unknown upstream|downstream hooks in router config.

Meaning:
1) if a given AS-A did not publish an rpki-as-cone object, then both upstream and downstream ASNs would be UNKNOWN relative to this AS-A.
2) if a given AS-A published an rpki-as-cone object with AS X,Y, and Z as upstreams then AS-A->ASX/Y/Z in a path would be VALID, while AS-A->any other AS would be INVALID upstream
3) if a given AS-A published an rpki-as-cone object with AS 1,2,3 as customers to AS-X, then AS1/2/3->AS-A would be VALID where (AS-A->AS-X), and any other AS->AS-A here would be INVALID (undeclared customer for upstream)

This would allow for semantics like:
If (path contains INVALID upstream) or (path contains undeclared customer) or (origin invalid [ROA origin validation) then drop

It would also allow for incremental uptake. Any AS can protect themselves a bit better by publishing a signed policy, but if you don’t then there is no difference from today. RPKI Validators can do the leg work for the crypto, so implementation in routers would require some memory and CPU, but nothing too drastic - similar to rpki-rtr and ROAs today.

Tim