Subject: [GROW] I-D Action: draft-ietf-grow-rpki-as-cones-00.txt

From: [email-masked]
Date: Fri, 07 Sep 2018 04:47:17 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Global Routing Operations WG of the IETF.

        Title           : RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous Systems Numbers To Facilitate BGP Filtering
        Authors         : Job Snijders
                          Massimiliano Stucchi
	Filename        : draft-ietf-grow-rpki-as-cones-00.txt
	Pages           : 8
	Date            : 2018-09-07

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-grow-rpki-as-cones/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-grow-rpki-as-cones-00
https://datatracker.ietf.org/doc/html/draft-ietf-grow-rpki-as-cones-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 7 Sep 2018 21:48:34 +0100

This probably doesn't suck as an idea.

One of the shortcomings of as-sets in RPSL was that there was no forward 
security when including as-sets.  In other words, anyone could include 
any other AS or as-set in their own as-set.  This allowed a good degree 
of flexibility, but could also create hilariously obnoxious results, for 
example the time that someone included AS-SET-INEX-RS in their own 
as-set, then did an AS7007 job towards INEX's route servers.  Much code 
was written in anger that day, oh yes, there was.

Anyway, if there were moves to think about whether it would be possible 
to include some form of inclusion authorisation mechanism, that would 
solve some actual problems.

Nick

---

From: George Michaelson <[email-masked]>
Date: Sat, 8 Sep 2018 09:22:03 +1000

You have to state quite clearly WHO IS SIGNING. Whern you define a
signed object into RPKI, the critical question is the PKI validation
question: what meaning is applied to the RPKI resources associated
with the signature which validates the object.

You haven't stated anywhere what is in the signing EE certificate, or
whose certificate it is.

Clearly, in context, its the ASN which "owns" the cone. so the EE
certificate has to consist of the RFC3779 list of ASN which say "I am
the owner"

As I said at a microphone at least once, Semantically, I think you
have a problem because I believe the customer ASN are the ones who
give authority to you to be placed into a cone, but we disagree there.

Syntactically, I think you really need specific language to state the
signer is the ASN constructing the cone,  not the ASN inside the cone
object.

-George
On Fri, Sep 7, 2018 at 9:48 PM <[email-masked]> wrote:
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 11 Sep 2018 11:18:39 +0200

Hi,

There is parallel, partly orthogonal, work in sidr-ops (no wg adoption yet):
https://tools.ietf.org/html/draft-azimov-sidrops-aspa-profile-00
https://tools.ietf.org/html/draft-azimov-sidrops-aspa-verification-00

This is essentially opt-in forward signing by a AS-‘x’ allowing to make an explicit list of upstream ASNs. If AS-X did not make a list, then any upstream is ‘unknown’. If they made a list and an upstream is not in it, then *that* upstream is ‘invalid’. Advice then is to drop invalids, but accept unknown and valid. This has similar semantics to ROA origin validation in that it allows outsourcing all the hard crypto work to validation software, and it allows for incremental deployment. It is not full path security like BGP Sec but it makes a path plausible, and in particular it makes it harder to do origin ASN spoofing — one would have to create longer and longer paths && more specifics would be rejected because of the ROA.

As far as I can tell the AS-cones is orthogonal to this in its simple form. It allows specifying the policy of which downstream ASNs (x,y,..) could be seen for a specific upstream ASN (z), relative to the ASN (a) in between. However, the ability to cite downstream ‘sets’ signed by others makes it very hard to reason about who signs what.

I think it could work if the two approaches were merged, and no downstream set inclusion is possible. e.g.. have an object where AS-X signs:

Upstreams AS-1 from AS-X:
          With downstreams forwarded to AS-1: ANY (null) -OR- None (empty list) - OR- AS 5, 6, 7 (specific list)
 Upstream AS-2 from AS-X, etc..

Signed AS-X

This would allow for the forward signing just like described in the ASPA verification document. To me this seems the most valuable, but it would also add a policy layer where certain downstreams may or may not be seen by an upstream. The downstream verification would then have the following states:

    ANY: all downstreams ‘valid' for this upstream
    LIST: cited downstreams ‘valid’, uncited downstreams ‘invalid’
    NONE: all downstreams ‘invalid’ for this upstream (empty list: they are all uncited)

It implies that this is always specified if the above object is made. However, if ASN-X did not create any object then both its upstreams, and downstreams, would be ‘unknown’.

The cryptographic validation can be done by validation software, and a router can get a simple list of tuples. The rpki-rtr protocol could be extended (something that should be done for aspa by itself anyway).

Going further, I know that part of the motivation of the AS-cones work is to provide feature parity with the IRR, and the above is only a subset. That said I think this would still allow for the creation of manual filter list of people are so inclined. As the upstream AS I can find all documented policies facing myself, and the ASNs that would be forwarded to me. Recursively I can find the policies facing those ASNs and the ANSs facing them. So I can still compile a list of all possible ASNs behind an ‘incoming’ ASN and using ROUTE objects and/or ROAs compile a list of allowed prefixes.

Kind regards,

Tim

> On 8 Sep 2018, at 01:22, George Michaelson <[email-masked]> wrote:
> 
> On Fri, Sep 7, 2018 at 9:48 PM <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/i-d-announce <https://www.ietf.org/mailman/listinfo/i-d-announce>
>> Internet-Draft directories: http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
> 
> GROW mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/grow <https://www.ietf.org/mailman/listinfo/grow>