[Sidrops] comments on the AS-Cones draft

[Stephen Kent <[e-mail]>]

I noticed that a draft describing Autonomous Systems Cones is on the 
agenda for tomorrow.

I reviewed this ID as though I were performing a SECDIR review of a 
draft. Thus my comments focus on document clarity and security, rather 
than routing-specific issues.

Section 1

The introduction needs to better explain the motivation for creating 
these objects, e.g., a desire to reproduce the functionality of the RPSL 
AS-Set data structure in the RPKI context. The allusion to RFC 6480 
should be replaced with an explicit statement that you are defining two 
new types of signed objects to be stored in the RPKI, to convey the data 
that is present in the RPSL structure. The reader should not have to 
wait until Section 3 to learn this.

Section 2:

This description is confusing, at best. The text here should cite RFC 
6488 and note that the AS-Cone and Policy Definition objects use of the 
CMS object format defined in that RFC. Note that the OIDs assigned to 
these two types of signed objects are defined later in the document. The 
ASN.1 for the 6488-level definition of signed objects should appear here.

2.1

A policy definition object contains a list of the upstream and peering 
relationships for a given Autonomous System that need an AS-Cone to be 
used for filtering.

->

A policy definition object contains a list of the upstream and peering 
relationships for a given Autonomous System that may wish to use an 
AS-Cone for filtering.

The text provides a description of the default behavior for a neighbor 
in the absence of an AS-Cone and associated policy, but it doesn’t even 
hint at the expected behavior when the AS-Cone and policy objected are 
present. I suggest adding text here to provide a preview of that 
behavior as described later.

It’s odd to call out and explain the Contact e-mail field before 
describing the other fields. I suggest describing each field in the 
Policy Definition object in this subsection. The subsequent text about 
how to accommodate multiple ASNs is confusing absent such a description. 
Also, no rationale is provided for why this restriction on ASNs is imposed.

2.1.1

The sentence here really should cite the variable ASCone when describing 
the naming convention, to avoid confusing the reader. Also, the text 
refers to a Policy object, not a Policy Definition object. Why?

2.1.2

The ASN.1 definition here should precede the discussion of fields in the 
object. Then each field should be described, in order. It’s not obvious, 
for example, why there is a LastModified time as well as a Created time. 
Neighbor is defined as a SEQUENCE vs. a SET. Is the ordering imposed by 
the SEQUENCE significant? Also, why not begin the structure with the AS 
number as an identifier? It seems odd to begin with the Neighbor 
sequence. The OID to be used in the 6488 object structure should be 
defined here.

There are two timestamps here, but the 6488 object structure optionally 
contains a timestamp that probably is equivalent to the LastModified 
variable here. The text should indicate whether the 6488 SigningTime 
value MUST be omitted, and thus LastModified is needed, or …

2.1.3

The text here is confusing. In 2.1.1 we’re told that a Policy 
(Definition?) object is named by suffixing an ASN to the string “AS” but 
here it appears that the object name also includes the ASN of the 
neighbor for which the object is destined. Which is correct?

2.2

The definition of AS-Cone is presented recursively, which is OK, but 
then it’s redundant to say, in the final sentence, that an AS-Cone can 
reference another AS-Cone.

The ASN.1 for this object should be the first part of this section, not 
buried in 2.2.4

2.2.1

This description of how the verification status of a AS-Cone is managed 
should come after the description of the semantics of the field. Also, 
it appears that the status change is the result of an e-mail exchange 
between two ASN operators. If the AS-Cone is to be consumed by other 
ASNs, how are they able to verify that the indicated status is accurate? 
This seems to be an aspect of the AS-Cone that cannot be verified using 
RPKI data- an RP is relying on the AS operator to have accurately 
reported this status. Having applied a signature to this data does not 
make it accurate.

2.2.2

Need a definition of a “third party” cone. This is the first mention of 
a responsibility for an RIR with respect to these objects. The 
discussion of such authentication is rather vague. Also, it’s not clear 
how a third party can independently verify that such authentication has 
taken place.

2.2.3

AS-Cones MUST have a unique name for the ASN they belong to. Names are 
composed of ASCII strings up to 255 characters long and cannot contain 
spaces.

In order for AS-Cones to be unique in the global routing system, their 
string name is preceded by the AS number of the ASN they are part of, 
followed by ":". For example, AS-Cone "EuropeanCustomers" for ASN 65530 
is represented as "AS65530:EuropeanCustomers" when referenced from a 
third party.

->

Each AS-Cone carries a name that MUST be globally unique. Names are 
composed of ASCII strings up to 255 characters long and cannot contain 
spaces.

To ensure uniqueness, the name for an AS-Cone begins wit ”AS” followed 
by the ASN of the AS in question, followed by a colon (“:”) and a text 
string describing the AS-Cone.

The mention of a “third party” in the original text is confusing. Also, 
why is the name a VisibleString? Only ASCII characters are allowed 
according to the opening sentence. In contrast, the VisibleString data 
type accommodate all IA5 characters. Did the text mean to say 
International ASCII, or should the ASN.1 data type be just 
PrintableString, or …?

2.2.4

As noted earlier, the syntax should begin this subsection, and the OID 
for this object in the RPKI object format should be specified here.

3.

I think this section should begin with an overview explaining how the 
data already present in the RPKI relates to these new objects. Other 
RPKI objects have clear limits on their semantics, based on the 
hierarchic structure imposed by the 3779 extensions. A similar 
explanation about how bad AS-Cones or Policy Definitions are detected 
and rejected, based on existing RPKI objects, is required here.

What is a “full AS-Cone”? The text defines a Policy Definition Object 
and an AS-Cone object, but I didn’t see an indication of what 
constitutes a “full” AS-Cone.

This section title refers to validation, but it really appears to be a 
description of how to construct AS path filters, right?

I see no description of object validation here, other than the reference 
to 6488. That reference is not sufficient to define validation for these 
two new objects. Note that every RPKI signed object using the 6488 
structure has a companion RFC that describes both the syntax and the 
validation procedure for that object. That procedure needs to be 
described here, for both object types, consistent with the section 
title. For example, if the Created or LastModified dates are in the 
future, is the object invalid? What if the Created date is later than 
the LastModified date? Are there any checks to be performed on the list 
of ASNs in an AS-Cone or Policy Object?

After the validation discussion, a new section should describe the AS 
path filter construction process. There are too many questions in the 
preceding sections for me to be confident that I can follow the details 
here, so I stooped trying to carefully examine the text. Also, there is 
reference to an “ASX Default policy” but I don’t recall seeing that term 
defined before. Finally, the process is described in a fashion that 
makes it very hard to follow, given the combination of iteration and 
recursion (as noted in step 6).

Since I stopped reviewing at Section 3, I did not review Sections 4 or 5.