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

From: [email-masked]
Date: Tue, 05 Mar 2019 01:40:15 -0800

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-01.txt
	Pages           : 8
	Date            : 2019-03-05

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-01
https://datatracker.ietf.org/doc/html/draft-ietf-grow-rpki-as-cones-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-rpki-as-cones-01

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: Brian Dickson <[email-masked]>
Date: Tue, 26 Mar 2019 19:35:46 +0100

Hi, GROW folks.

I'd like to offer some suggestions and explanations for them, on the
AS-CONES draft.

I'll make this brief, and as such, will include only the conceptual parts,
rather than explicit text.
It should be relatively easy for the authors to incorporate them.

Very briefly:

The as-cone targets, even when they are leaf AS, always need to be entities
that contain the AS number, plus a list of the AS's transit providers and
peers.
This object needs to be signed by the target AS (aka child AS).

The downward links should be treated as informative, and the upward links
as authoritative.

An as-cone validation should exclude any member AS which does not have a
signed object containing the as-cone's AS as one of its transit ISPs.

Only the customer can authoritatively declare its transit provider(s), not
the other way around.

Otherwise, random small networks could claim one or more Tier-1 ISPs as
their customers, and abuse all of the trust mechanisms that the as-cone
draft offers.

This view is much more consistent with how ROAs function; it is the
delegatee who signs the ROA (the more specific prefix), not the delegator.

Let me know if the above isn't clear or needs more explanation.

Thanks,
Brian

---

From: Brian Dickson <[email-masked]>
Date: Tue, 26 Mar 2019 19:38:26 +0100

Hi, GROW folks.

Very briefly:

Thanks,
Brian