Subject: Re: [Sidrops] Minor comments on draft-ietf-sidrops-aspa-profile-00

From: Alexander Azimov <[email-masked]>
Date: Sun, 6 Oct 2019 23:46:19 +0300

Hi Tim!

Thank you for the detailed overview.

Correct if I'm wrong, the mentioned problem with rsync can also affect
ROAs, am I right? For ROA it is just less critical since prefixes with
multiple originators are not the majority of the routing table.

ср, 21 авг. 2019 г. в 12:11, Tim Bruijnzeels <[email-masked]>:

> Hi all,
>
> Triggered by an email exchange with Alexander, I figured I would send my
> (minor) comments on the aspa profile to the list as well.
>
> = Multiple "providerASID"
>
> For ASPA verification it's important that routers get all "providerASIDs"
> for a "customerASID". Since it's a single "customerASID" who signs the ASPA
> I think it would be best to allow all "providerASIDs" in a single object.
> Like so:
>
> OLD:
>        ASProviderAttestation ::= SEQUENCE {
>            version [0] ASPAVersion DEFAULT v0,
>            AFI  AddressFamilyIdentifier,
>            customerASID  ASID,
>            providerASID  ASID }
>
> NEW:
>        ASProviderAttestation ::= SEQUENCE {
>            version [0] ASPAVersion DEFAULT v0,
>            AFI  AddressFamilyIdentifier,
>            customerASID  ASID,
>            providerASID  SEQUENCE (SIZE(1..MAX)) OFASID }
>
>
> Of course it's possible to make separate ASPA objects for each
> "providerASID", but I think it introduces avoidable risks with no clear
> benefits. When managing separate objects signing CAs would need to make
> sure that they publish changes as a set. If RPs use rsync as the fetch
> protocol they may learn of some, but not all, objects if the repository is
> being updated just as they are fetching.
>
> The use of RRDP can mitigate this issue, but having a single object in
> this case is cheap and avoids some of the risks. An RP would always see the
> full set (for the moment that it validates).
>
>
> = Small EE certs
>
> The draft currently has:
>
>       The autonomous system identifier delegation extension [RFC3779] is
>       present in the end-entity (EE) certificate (contained within the
>       ASPA), and the customer AS number in the ASPA is contained within
>       the set of AS numbers specified by the EE certificate's autonomous
>       system identifier delegation extension.
>
> I think it's better practice to require that:
>
>       The autonomous system identifier delegation extension [RFC3779] MUST
>       be present in the end-entity (EE) certificate (contained within the
>       ASPA), and MUST contain a single AS number that matches the customer
>       AS number. The IP address delegation extensions MUST NOT be used.
>
> The reason for this is fate-sharing. If any of the other irrelevant
> resources on the EE certificate would no longer be contained on the CA
> certificate - e.g. because of a resource transfer - then the object as a
> whole would become invalid.
>
> There is still discussion about transfers and the deployment of
> 'reconsidered' validation rules. But.. I think that's best discussed
> outside of this draft. Here it seems that the problems can simply be
> avoided by having a single AS on the EE cert.
>
>
> = Add file extension to section 6 (IANA considerations)
>
> In addition to the OIDs I believe a filename extension should be
> registered.
>
>    IANA is to add an item for the Signed TAL file extension to the "RPKI
>    Repository Name Scheme" created by [RFC6481] as follows:
>
>           Extension  |   RPKI Object              | References
>           -----------+-------------------------------------------
>            .asp      |   Trust Anchor Keys        | [this document]
>
> (of course feel free to chose another extension - I think four characters:
> .aspa would also be fine)
>
> File extensions were introduced to help RPs in parsing - so they don't
> have to do trial an error parsing of objects as all possible types. The
> OIDs are not quite enough, because certificates and CRLs are not RPKI
> signed objects.
>
>
> Kind regards
>
> Tim
>
>
>
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops
>

-- 
Best regards,
Alexander Azimov

---

From: Randy Bush <[email-masked]>
Date: Sun, 06 Oct 2019 17:07:36 -0700

i have not thought deeply abut this.  but it seems to me that, as in
ROAs, one enters into and leaves relationship with a provider.  whacking
a multi-AS ROA or a multi-provider ASPA record seems ill advised.  for
example, what if there is a delay between delete and recreate?

keep things simple, please.

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 7 Oct 2019 10:21:50 +0200

Hi Randy, Alexander (this should also answer your point), all

> On 7 Oct 2019, at 02:07, Randy Bush <[email-masked]> wrote:
> 

I am all for keeping things simple, but we may have different ideas of what is simple :) We can also do multiple ASPA files, but I don't think that it's really much simpler and because there are more files involved I think there are more chances of delays between publish, withdraw and updates.

Let me try to make the case once more for single objects with multiple provider ASNs. TL;DR: I still think it's slightly better, but it's not a showstopper to me. And contrary to ROAs there is no fate sharing issue here.

= Simplicity

Looking at how I would implement this (hopefully in the near future!) I would let users of the CA software configure which ASNs they want to authorise as the next hop after their own ASN. Suppose that I can create a single object with all these ASNs, I would publish this all in a single signed object with a determinate name, e.g. based on the key identifier of the CA certificate key, just like is commonly done for CRLs and MFTs. Then, whenever there is an update, I would publish a new object in place of the old. To me this is actually simpler than maintaining multiple objects. It also ensures that there is no delay between delete and recreate. 

= Mismatches (race condition between RP and CA/publisher)

In the remote, but possible, event that an RP which uses rsync gets the updated ASPA file, but the old MFT - or vice versa, then the outcome is dependent on local interpretation of section 6.6 of RFC6486 (Hash Values Not Matching Manifests), but in most implementations that I know it would lead to rejection of the ASPA object. Some implementations might accept it and warn. But whatever the case, if a single object is used this would mean that there is either a complete set of upstream ASNs, or the set is empty - which would mean that all customer-provider checks fall back to "unknown" (https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-01#section-4 <https://tools.ietf.org/html/draft-ietf-sidrops-aspa-verification-01#section-4>).

Note that CAs using RRDP will publish the new MFT, CRL and ASPA object as a single delta, and therefore RPs supporting RRDP would not be affected by this issue.

= Analogy to ROAs

As for ROAs, I think the ship has sailed on the spec. 

ROAs can have multiple prefixes, which are 'signed' (through the EE cert etc etc), and a single ASN. There has been discussion in sidrops (and sidr?) regarding not putting multiple prefixes on ROAs, as the spec allows. The main reason being that the loss of any one resource in any prefix would invalidate the ROA as a whole; all prefixes would be 'fate-sharing'. So there was advice to only use a single prefix per ROA, or well I suppose that more specific sub-prefixes are okay, e.g. if there is a /20 on a ROA, then rather than having a global max length it would be fine to have explicit more specific /24s there. However, I don't think that this advice has been incorporated in a formal BCP. I think that RFC7115, BCP-185, "Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)" predates this discussion.

Since ASPA object have a single "customerASID" which has to appear on the signing EE certificate, so for ASPA this fate sharing is not an issue, as long as the issuing CA uses a small EE cert with just that single ASN (as I suggested in my previous email).

Tim

---

From: Jay Borkenhagen <[email-masked]>
Date: Mon, 7 Oct 2019 07:56:48 -0400

I would like to re-emphasize one point Tim made (without diminishing
his others):

Tim Bruijnzeels writes:
 > But whatever the case, if a single object is used this would mean
 > that there is either a complete set of upstream ASNs, or the set is
 > empty - which would mean that all customer-provider checks fall back
 > to "unknown"

It's critical that users of ASPA data operate using a complete set of
an ASN's authorized upstream ASNs.  The simplest way to communicate
such a verifiably-complete set is to use a single object.

Thanks!

					Jay B.

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 7 Oct 2019 13:31:51 +0100

> such a verifiably-complete set is to use a single object.

bits of me agree with this, but other bits not.  It's shifting the 
problem from an RPKI database synchronisation problem to a 
human-oriented data synchronisation problem.  Both are hideously 
difficult problems to solve, but the one which involves human input is 
almost certainly less reliable.

Nick

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 7 Oct 2019 22:27:29 +0000

If the customer-provider objects are individual, then a relying party
may have a partial list of providers for one customer.

If all the providers for one customer are in a single object,
then, upon a change, the RP can have either the old object
or the new object, but never a partial view.

A partial view, IMO is worse that having the old view a little longer
than possible. A partial view can cause some AS-paths to be considered
invalid when they are not.

Regards,
Jakob.

-----Original Message-----
From: Sidrops <[email-masked]> On Behalf Of Nick Hilliard
Sent: Monday, October 7, 2019 5:32 AM
To: Jay Borkenhagen <[email-masked]>
Cc: SIDR Operations WG <[email-masked]>
Subject: Re: [Sidrops] Minor comments on draft-ietf-sidrops-aspa-profile-00

Nick

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 8 Oct 2019 08:49:15 +0200

Hi,

So, to re-iterate: I don't think the problem of getting only a sub-set of ASPA objects is very likely to occur, especially when using RRDP. With RRDP there are deltas that provide transactionality in publication, which at least allows operators to publish multiple objects as a single delta. But, of course, their CA software has to support this idea, rather than publish objects (+mft + crl) one by one.

However, having the option of multiple provider ASNs in a single object allows for a publication strategy (using a fixed named object) that avoids the issue altogether, as a bonus I find it a bit easier to manage for my particular implementation, and it saves a bit of space (CMS wrapping, EE cert 2048 with bit key). And on the other hand, I don't think that having:

	providerASID  SEQUENCE (SIZE(1..MAX)) OF ASID 

Instead of:

	providerASID  ASID

adds much in terms of complexity, and I do not see any other clear drawbacks (e.g. fate sharing).

If multiple provider ASNs are allowed I would go on to RECOMMEND that a single object is used, but in principle implementations can still have multiple ASPA objects, each with a SEQUENCE OF 1 ASID. I expect that RPs will validate ASPA objects and build up a list of 'Validated Customer Provider Relations', and that this list/deltas - excluding duplicates - is communicated to routers in a new version of the RPKI-RTR protocol. So, it should not matter if the relations were found on 1 or more objects.

In ROAs we can only have one ASN, so multiple are needed in case a prefix is multi-homed. Although, in retro-spect multiple ASNs could have been a nice idea here too, but I don't think the problem is anywhere near big enough to warrant a re-design of the ROA spec.

Tim

> On 8 Oct 2019, at 00:27, Jakob Heitz (jheitz) <[email-masked]> wrote:
>

---

From: Alexander Azimov <[email-masked]>
Date: Mon, 14 Oct 2019 23:59:18 +0300

Hi all,

I would try to summarize the points that were presented in this thread.

The question is whether we should define ASPA like it was done for ROAs or
should we do it in a slightly different and slightly more reliable manner.
The data structure that we need at the router to verify ASPATH is a simple
{customer: set of providers}. And to have a reflection of such tuple it in
one RPKI object seems to be native (+ all points that were listed above).
If we unbound ASPA object structure from ROA-like structure we may also get
rid of ASPA0 - empty set is a simple form to signal that ASN does not have
any transit providers. So, the spec should say:

providerASID  SEQUENCE (SIZE(0..MAX)) OF ASID

In this case, to signal that prefix should not be seen in the BGP
default-free zone ROA0 should be issued; to signal that ASN
is provider-free ASPA-EMPTY (instead of ASPA0) should be issued. If we
believe that this will not add ambiguity for the users I'm ok to change it.

вт, 8 окт. 2019 г. в 09:49, Tim Bruijnzeels <[email-masked]>:

> Hi,
>
> So, to re-iterate: I don't think the problem of getting only a sub-set of
> ASPA objects is very likely to occur, especially when using RRDP. With RRDP
> there are deltas that provide transactionality in publication, which at
> least allows operators to publish multiple objects as a single delta. But,
> of course, their CA software has to support this idea, rather than publish
> objects (+mft + crl) one by one.
>
> However, having the option of multiple provider ASNs in a single object
> allows for a publication strategy (using a fixed named object) that avoids
> the issue altogether, as a bonus I find it a bit easier to manage for my
> particular implementation, and it saves a bit of space (CMS wrapping, EE
> cert 2048 with bit key). And on the other hand, I don't think that having:
>
> If multiple provider ASNs are allowed I would go on to RECOMMEND that a
> single object is used, but in principle implementations can still have
> multiple ASPA objects, each with a SEQUENCE OF 1 ASID. I expect that RPs
> will validate ASPA objects and build up a list of 'Validated Customer
> Provider Relations', and that this list/deltas - excluding duplicates - is
> communicated to routers in a new version of the RPKI-RTR protocol. So, it
> should not matter if the relations were found on 1 or more objects.
>
> In ROAs we can only have one ASN, so multiple are needed in case a prefix
> is multi-homed. Although, in retro-spect multiple ASNs could have been a
> nice idea here too, but I don't think the problem is anywhere near big
> enough to warrant a re-design of the ROA spec.
>
> Tim
>
>
>

-- 
Best regards,
Alexander Azimov

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 14 Oct 2019 21:49:09 +0000

I think the ultimate test of whether an AS-path conforms to policy is that the as-path contains only ASNs that are authorized by the endpoints to carry traffic between the endpoints. ASPA is a blunt hammer to achieve this. To be sure, I think it hits most of the nails and for the nails it misses, it has siblings. I want to leave the door open to improve it so it can hit more nails.

One improvement would be to add a prefix-set to a provider: The stated provider is provider for the stated prefixes. Another would be to give an AS the ability to exclude any ASNs from anywhere in the AS-path that it is an endpoint of, even if its upstreams allow it. This would have to be conditional on a prefix-set at least.

The time for such enhancements is not now and may never happen, but we should think about it when choosing the format for the object.

Regards,
Jakob.

From: Sidrops <[email-masked]> On Behalf Of Alexander Azimov
Sent: Monday, October 14, 2019 1:59 PM
To: Tim Bruijnzeels <[email-masked]>
Cc: SIDR Operations WG <[email-masked]>; Jakob Heitz (jheitz) <[email-masked]>; Jay Borkenhagen <[email-masked]>; Nick Hilliard <[email-masked]>
Subject: Re: [Sidrops] Minor comments on draft-ietf-sidrops-aspa-profile-00

Hi all,

The question is whether we should define ASPA like it was done for ROAs or should we do it in a slightly different and slightly more reliable manner.
The data structure that we need at the router to verify ASPATH is a simple {customer: set of providers}. And to have a reflection of such tuple it in one RPKI object seems to be native (+ all points that were listed above). If we unbound ASPA object structure from ROA-like structure we may also get rid of ASPA0 - empty set is a simple form to signal that ASN does not have any transit providers. So, the spec should say:

In this case, to signal that prefix should not be seen in the BGP default-free zone ROA0 should be issued; to signal that ASN is provider-free ASPA-EMPTY (instead of ASPA0) should be issued. If we believe that this will not add ambiguity for the users I'm ok to change it.

вт, 8 окт. 2019 г. в 09:49, Tim Bruijnzeels <[email-masked]<mailto:[email-masked]>>:
Hi,

Instead of:

        providerASID  ASID

Tim

> On 8 Oct 2019, at 00:27, Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:
>
> From: Sidrops <[email-masked]<mailto:[email-masked]>> On Behalf Of Nick Hilliard
> To: Jay Borkenhagen <[email-masked]<mailto:[email-masked]>>
> Cc: SIDR Operations WG <[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
Sidrops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sidrops

--
Best regards,
Alexander Azimov

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 15 Oct 2019 11:12:24 +0200

Hi Alexander,

> On 14 Oct 2019, at 22:59, Alexander Azimov <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi all,
> 

I am leaning towards (ab)using AS0 again. I can live with empty sets, but then we need to be okay with the impact on the RTR protocol (which is still to be defined).

The empty set makes sense to me from the perspective of the ASPA profile. But it begs the question: what if multiple ASPA objects exist for the same customer AS. And one uses the empty set, and others don't. I would expect that the union of all provider ASNs from all objects are accepted. I.e. the empty set on one object cannot negate other objects. I don't expect that people will disagree with this (but please speak up if you do!) - but, this will need to be spelled out explicitly.

We still need an RTR extension to communicate the data to routers. If this is done similar to ROAs then I would expect data structures like:

   0          8          16         24        31
   .-------------------------------------------.
   | Protocol |   PDU    |                     |
   | Version  |   Type   |         zero        |
   |    2     |    X/Y   |                     |
   +-------------------------------------------+
   |                                           |
   |                 Length=16                 |
   |                                           |
   +-------------------------------------------+
   |                                           |
   |      Customer Autonomous System Number    |
   |                                           |
   +-------------------------------------------+
   |                                           |
   |      Provider Autonomous System Number    |
   |                                           |
   `-------------------------------------------'

Where X indicates 'announce', and Y indicates 'withdraw', similar to the flags in RFC8210 section 5.6. (Or.. an explicit flag is introduced in the header - no strong opinion on that..)

Question then is how to communicate the empty set. You would probably need a new PDU for that with its own PDU type (~Z) where there is no Provider ASN, like:

   0          8          16         24        31
   .-------------------------------------------.
   | Protocol |   PDU    |                     |
   | Version  |   Type   |         zero        |
   |    2     |    Z     |                     |
   +-------------------------------------------+
   |                                           |
   |                 Length=12                 |
   |                                           |
   +-------------------------------------------+
   |                                           |
   |      Customer Autonomous System Number    |
   |                                           |
   +-------------------------------------------+

And if there were 'announce' tuples sent earlier, then the cache would have to send a 'withdraw' for each of those as well.

In that regard using AS0 may be easier. AS0 is just another AS that you will never see in the wild for other reasons. Using it in RTR eliminates the need for an extra PDU type, and if we use it there then I think we should also use it in the ASPA profile for consistency and easier reasoning between what you see in a router, and what is published.

Tim

> 
> вт, 8 окт. 2019 г. в 09:49, Tim Bruijnzeels <[email-masked] <mailto:[email-masked]>>:
> Hi,
> 
> > On 8 Oct 2019, at 00:27, Jakob Heitz (jheitz) <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > From: Sidrops <[email-masked] <mailto:[email-masked]>> On Behalf Of Nick Hilliard
> > To: Jay Borkenhagen <[email-masked] <mailto:[email-masked]>>
> > Cc: SIDR Operations WG <[email-masked] <mailto:[email-masked]>>
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/sidrops <https://www.ietf.org/mailman/listinfo/sidrops>
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/sidrops <https://www.ietf.org/mailman/listinfo/sidrops>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sidrops <https://www.ietf.org/mailman/listinfo/sidrops>
> 
> 
> -- 
> Best regards,
> Alexander Azimov

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 15 Oct 2019 15:35:19 +0200

Hi Jakob, all,

> On 14 Oct 2019, at 23:49, Jakob Heitz (jheitz) <[email-masked]> wrote:
> 

I am not convinced about that. The object has a distinct OID and version, either of which could be updated by possible future versions.

Tim