Subject: [Sidrops] [WGLC] draft-ietf-sidrops-8210bis-03 - Ends 7/December/2021

From: Keyur Patel <[email-masked]>
Date: Tue, 23 Nov 2021 19:00:31 +0000

Hi Folks:

A working group last call has been requested for draft-ietf-sidrops-8210bis-03, “The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2”. Please reply to the list with your comments. The WGLC will end on December 7th, 2021.

The draft can be found at https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-8210bis. Authors, please reply indicating whether you're aware of any relevant IPR that hasn't been disclosed.

Regards,
Nathalie, Chris & Keyur

---

From: Job Snijders <[email-masked]>
Date: Wed, 24 Nov 2021 11:29:57 +0100

Hi all,

Is there at least two implementation reports I can review? If yes,
where?

Kind regards,

Job

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

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 24 Nov 2021 12:10:53 +0100

Hi all,

I still have some issues with the ASPA PDU as defined here.

I am not necessarily opposed, i.e. I am open to be convinced otherwise, but I do not see a very strong reason for having big, per AFI, PDUs which "MUST deliver entire data of an ASPA record in a single ASPA PDU".

I understand that there is an intent to avoid / minimise race conditions, but I am not fully convinced that this is the best way to achieve this.

I think that a model similar to multiple ROA objects and resulting VRP PDUs is preferred. 

Even though we instruct CAs to use a single ASPA per customer AS, situations may arise where multiple valid ASPA objects exist - e.g. because of transfers, or because of SLURM (which I think should be extended for ASPA). It would be much more intuitive to me that RPs would therefore derive "Validated ASPA Payloads" (VAP) - essentially tuples of: (AFI, Customer AS, Provider AS). And that "announcement" and "withdrawal" of these individuals VAPs would be communicated as PDUs - similar to the IPv4 and IPv6 payloads.

I think it should be possible to avoid race conditions because a single update can contain multiple such PDUs. They could be sorted by customer AS to help routers further. I think we can expect then that a router applies all updates for customer AS - provider AS mappings in an atomic way. And if they can't then I do not see how they would do any better in case the PDU always has the full new list (per AFI). The same can be achieved locally by making a new copy of an existing provider list for a customer as, apply the delta, and then replace the original list with the copy.

So to me the advantage of having the smaller "VAP" announcement/withdrawal PDU would be that it:
- is similar to ROAs so more consistent and intuitive to implement,
- deals well with the possibility of multiple objects which cannot be prevented,
- reduces overhead in updates.

As I said, I have an opinion on this, but I am truly open to hear what others have to say - router implementers in particular - because of the possible race condition mentioned in case routers apply updates naively.

Tim

> On 23 Nov 2021, at 20:00, Keyur Patel <[email-masked]> wrote:
> 
> Hi Folks:
>

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Wed, 24 Nov 2021 19:20:39 +0000

Hi all,

I too have some issues with the current version of the draft. First the processing of the ASPA PDU{11} breaks with the processing flow compared to all other data PDUs: PDU{4}, PDU{5}, and PDU{9}. Second the Flags field specification is ambiguous, and third the encoding of the AFI bit conflicts RFC 6482.

1.) ASPA PDU processing:
========================
To refresh our memories, PDU{4} and PDU{5} (ROA data) as well as PDU{9} (BGPsec key data) work in an (announce / withdraw) mode controlled with the Flags field. Each PDU is carrying a single data point. 
For instance, a ROA that contains "n" prefixes results in "n" data PDUs. The Flags field identifies what to do with the data point, add it or remove a previous received matching one. Also, the cache must not send the same data PDU twice or the router returns an error.

Very simple for the router to process!!

Now the ASPA PDU{11} functions somewhat different and breaks with the processing flow used in all the other data PDUs.
 
First it uses a single PDU{11} for all customer provider relations of the same AFI. Second it introduces the concept of “implicit” withdrawal in addition to the “explicit” withdrawal which is signaled using the Flags field’s “withdrawal” flag. 
Regarding the “implicit” withdrawal, the draft reads:

| Receipt of an ASPA PDU announcement
| when the router already has an ASPA PDU with the same Customer
| Autonomous System Number and the same Address Family (see Flags
| field), replaces the previous one.  This is to avoid a race condition
| when a BGP announcement is received between an withdrawn PDU and a
| new announced PDU.

Now, the PDU "announce" process for a never-before-seen customer AS is the same as with all other data PDUs. New data is received - add it – done, very simple! 
It becomes tricky when this data gets “updated”. Here the router receives a PDU with the “announce” flag set and a different list of provider ASs which leads to an “implicit” withdrawal of the missing provider ASs. 

For instance: (customer-as) (provider-as) (provider-as) …
1st PDU: 65000 65001 65002 65003
2nd PDU: 65000 65001 65003 65004

The issue here is that the router is tasked with identifying the customer-provider relations that are missing from the newly provided list compared to the previous list. (here: 65000-65002 is implicitly withdrawn and 65000-65004 is announced).

What about if the cache sends the same PDU twice? Should the router respond with a Duplicate Announcement Received Error? No mention about that, so it would be legal in this case. At least I can imagine some different implementations in this regard.

To remove all customer-provider relations the cache needs to re-send the 2nd PDU with the “delete” flag set because the cache cannot just send a PDU{11} with an empty provider set. The length field must not be 0. 

To align ASPA with all other PDUs and remove any unnecessary complexity, a modification of PDU{11} to the format shown below is in my mind the most feasible solution:

   0          8          16         24        31
   .-------------------------------------------.
   | Protocol |   PDU    |          |          |
   | Version  |   Type   |   Flags  |   zero   |
   |    2     |    11    |          |          |
   +-------------------------------------------+
   |                                           |
   |    Customer Autonomous System Number      |
   |                                           |
   +-------------------------------------------+
   |                                           |
   |    Provider Autonomous System Number      |
   |                                           |
   +-------------------------------------------+

Using this allows simple delta updates by adding and removing a single customer-provider relationship as done for ROA and BGPsec Key information. Also, it removes the implicit withdrawal. The router process flow for this PDU matches the process flow for any of the other data PDUs.

Furthermore, it solves all issues mentioned in an earlier thread with the current length field.

Regarding the statement of racing conditions, the router should never act upon partial received data from the cache anyhow – that was already identified many years ago for ROAs. I believe Ruediger spoke to that on the mic during IETF week some time ago. Performing route origin validation in the middle of receiving ROA updates leads to all kind of issues. The protocol has an “End of Data” PDU{7} which signals that all data is send/received and it is safe to start/resume processing of any validation on the routers side. Any racing condition related to this protocol are eliminated if the router follows the simple rule of “suspend all validation during a cache update”. Or use the old information until the data is updated and then switch over to the new data set. But all that should have been done already for route origin validation. I do not see the need for special treatment of ASPA data here, ASPA does not introduce any new problem space in this regard!

I read scanned through the document and could not find anything in this regards, maybe that is a good point to add wording.

2.) Flags field:
================
The second major issue I have is related to the Flags field and AFI. Currently the draft has two ambiguous specifications of the Flags field. The first definition is in section 5.1 Fields of PDU. 

This section currently reads:

| Flags:  The lowest-order bit of the Flags field is 1 for an
|      announcement and 0 for a withdrawal.  For a Prefix PDU (IPv4 or
|      IPv6), the flag indicates whether this PDU announces a new right
|      to announce the prefix or withdraws a previously announced right;
|      a withdraw effectively deletes one previously announced Prefix PDU
|      with the exact same Prefix, Length, Max-Len, and Autonomous System
|      Number (ASN).  Similarly, for a Router Key PDU, the flag indicates
|      whether this PDU announces a new Router Key or deletes one
|      previously announced Router Key PDU with the exact same AS Number,
|      subjectKeyIdentifier, and subjectPublicKeyInfo.
|
|      The remaining bits in the Flags field are reserved for future use.
|      In protocol version 1, they MUST be zero on transmission and MUST
|      be ignored on receipt.

There is no mentioning of the ASPA PDU(11) though this PDU too does have a “Flags” field as well. This might be because “Section 5.12 ASPA PDU” contains its own definition for the Flags field which is different from the global definition listed above:

The Flags field is defined as follows:

|       Bit     Bit Name
|       ----    -------------------
|        0      Announce/Withdraw (ann == 1, with == 0)
|        1      AFI (IPv4 == 0, IPv6 == 1)
|        2-7    Reserved, must be zero

I don’t think this is a good idea to have a slightly different definition of the otherwise globally defined field. Either, have each PDU specify its own Flags field or use one single global specification as done so far. 

Now the difference between both specifications is in the AFI field, which does not exist yet in the global Flags definition. Adding AFI to the global definition though will introduce conflicts with PDU{4} and PDU{5} and nonsense for PDU{9}. PDU{9} is a key and therefore should not have any AFI specified at all. PDU{4} for IPv4 ROA data now could have an incorrect encoding of IPv6 AFI. Similarly PDU{5} for IPv6 ROA data could carry an IPv4 AFI encoding. This just adds unnecessary required sanity checks to the router. Possibly even a new Error. Therefore, I propose to use the “zero” field of PDU{11} for AFI information and leave the Flags field alone. With this, none of the other PDU’s are affected.

With this I propose the final PDU change:

   0          8          16         24        31
   .-------------------------------------------.
   | Protocol |   PDU    |          |          |
   | Version  |   Type   |   Flags  |   AFI    |
   |    2     |    11    |          |          |
   +-------------------------------------------+
   |                                           |
   |    Customer Autonomous System Number      |
   |                                           |
   +-------------------------------------------+
   |                                           |
   |    Provider Autonomous System Number      |
   |                                           |
   +-------------------------------------------+

3.) AFI encoding:
================
This brings me to the last issue I have: The AFI encoding in PDU{11}. 
Currently PDU{11} defines an AFI for IPv4=0 and for IPv6=1. I do understand, this is done to only use a single bit. RFC 6482 though specifies the AFI value for IPv4=1 and IPv6=2 which of course uses 2 bits. This is a bug feast in the waiting. Here using the encoding of RFC 6482 reduces the danger of introducing AFI related bugs in the code and a requirement of encoding the AFI value according to RFC 6482 is highly recommended, regardless of encoding it using 2 bits of the Flags field or in its own preferred AFI field as proposed above.

Thanks,
Oliver

-----------------------------------------------
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology
(Office) +1.301.975.4856

---

From: Randy Bush <[email-masked]>
Date: Sat, 27 Nov 2021 18:35:28 -0800

> I think that a model similar to multiple ROA objects and resulting VRP

From: Randy Bush <[email-masked]>
Subject: Re: [Sidrops] Minor comments on draft-ietf-sidrops-aspa-profile-00
To: Alexander Azimov <[email-masked]>
Cc: SIDR Operations WG <[email-masked]>, Tim Bruijnzeels <[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: Randy Bush <[email-masked]>
Subject: Re: [Sidrops] New Version Notification for draft-ymbk-8210bis-00.txt
To: Alexander Azimov <[email-masked]>
Cc: SIDR Operations WG <[email-masked]>
Date: Tue, 24 Mar 2020 12:02:10 -0700

> The current proposal addresses this issue for ASPA and ROAs in a different
> way:
> 
>    - For ASPA a single PDU per customer AS is neveling the issue;
>    - For ROAs the draft introduces ordering of the updates + suggests
>    sending updates with the same prefix back to back.
> 
> The way ROAs will be processed decreases the chances that valid prefixes
> will be marked as invalid, but they are not zero. My thinking is, that
> since RTR protocol is negotiating its version at the start of the session
> there is no need to keep full backward compatibility with the way ROAs were
> processed previously. Instead, we can change ROA RTR PDUs is the same
> fashion as it is introduced for ASPA: a single PDU for a selected prefix
> that replaces previous records.

two dimensions of why not

  o the ASPA is a single atomic assertion signed by the only party who
    has the authority.  it's pretty simple.

  o ROAs for a range are not atomic and may be asserted by many parties.
    e.g. a /15 with two delegated /16s, each with delegated /whatevers.
    if a /29 down the subnet-chain changes, you have to re-do the whole
    shebang.

    a number of these are likely to be via CA delegation; more and more
    as alex's marketing engine revs up.  so they will arrive at a cache
    skewed in time.

    think what this does to the load on the router; and remember that
    one major goal here is to minimize router load so current hardwhere
    running on 6502s with 640k can route origin validate.

and ask folk such as mark how rov deployment is going on some of the
more common platforms.

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 29 Nov 2021 12:17:06 +0100

> On 28 Nov 2021, at 03:35, Randy Bush <[email-masked]> wrote:
> 

I am all for simple, but you cannot assume there will only ever be one
valid ASPA object for a customer AS.

I know the profile text says the a CA MUST make a single ASPA for a customer,
and I agree. But there are a number of reasons why RPs need to be prepared to
see multiple valid ASPA objects in the RPKI:

1 CA migration make before break

Suppose that I want to change from one CA implementation to another, then
I want to ask my parent to authorise my new CA and set up everything, ROAs,
ASPAs etc before removing and breaking my old CA.

2 Parent publishing ASPA

A parent can publish an ASPA for my customer ASN, delegate the ASN to me,
and then I can publish a second ASPA. Ill advised indeed, but we cannot
assume it won't happen.

3 Multi TA

ASPA objects for the same customer ASN can appear in different trees, at
least in theory.

4 (future) Local exceptions (SLURM)

While this would not be an object as such, we can (and should) extend
SLURM to allow for local ASPA filters / additions. This could also cause
overlaps with actual objects.

5 Algorithm Roll?

I need to re-read this in detail (RFC 6916) but I think there may be
duplicate objects in there as well, though I am not sure whether RPs
are required to validate both for the same CA. But, there may be something
here too.

In short I think RPs should process all *valid* ASPA objects and then
derive the *union* of all providers for a given customer ASN and AFI.

Note that this is orthogonal to the question of whether that union should
be presented to routers as a single PDU, or that single provider announcement/
withdrawal PDUs could be used.

>    has the authority.  it's pretty simple.

See above, there can be, and therefore RPs must assume there will be, more
than one object.

>    running on 6502s with 640k can route origin validate.

I am all for reducing the load on routers.

How is presenting a single PDU with a provider list that is supposed to
replace the previous list better on routers than having multiple PDUs
in a single update - i.e. before the end of data as Oliver mentioned?

In the first case there is possible overhead in case lists get long,
the second puts some burden on the router to build up its own new version
of a list before replacing the one it had. I expect that burden to be
low, but if router implementers can attest that it isn't then I would
love to hear it.

As I said, multi ASPA objects is orthogonal. If we MUST have a single
PDU then the cache can send the union of providers in ASPA objects as
a single PDU.

> and ask folk such as mark how rov deployment is going on some of the

I don't know who you mean by mark and what you mean by this. If there
are lessons to be shared, then please share specifics.

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Mon, 29 Nov 2021 14:11:48 +0000

The current version of the draft mentions a router only contains one single APSA object per customer. This assumes a specific form of implementation. I don't believe a protocol specification should do that. One can imagine an implementation that stores the data as link relations hence multiple internal objects per customer. Take 10 implementers and you might end up with 10 solutions.

I always read to keep things simple - Great I like simple. Though, as I outlined in my email from last week, the current specification introduces implicit withdrawals while announcing an ASPA object. That contradicts simplicity - it adds additional complexity to the router.

As I mentioned in my email as well as was mentioned in prior IETF's a router should never perform any validation on incomplete data. The moment the router starts updating the data, it most likely will encounter a break before make situation - at least when it comes to ROA's. Therefore the router should always wait until a complete update is processed prior acting upon it.

Therefore, "Keep it simple" should result in a PDU as I proposed with only a single Customer Provider. An ASPA object that contains 10 providers should result in 10 PDU's each with the customer and a single provider. Duplicates are treated as established, withdrawals are treated as established. No special handling required on the router's side.

--> Simple!

Oliver

(GVoice) +1.240.668.4117

    2 Parent publishing ASPA

    A parent can publish an ASPA for my customer ASN, delegate the ASN to me,
    and then I can publish a second ASP?A. Ill advised indeed, but we cannot
    assume it won't happen.

    3 Multi TA

    5 Algorithm Roll?

    > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=04%7C01%7Coliver.borchert%40nist.gov%7C70d048bf3e5b49ef79c008d9b329f3d8%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637737815033219650%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=bbwNyYio7MY9HcS6y5c%2Fc%2F3be6thDWayfwQu77Vh7Dc%3D&amp;reserved=0

    _______________________________________________
    Sidrops mailing list
    [email-masked]
    https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=04%7C01%7Coliver.borchert%40nist.gov%7C70d048bf3e5b49ef79c008d9b329f3d8%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637737815033229605%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=YUOeX%2BFBPcBdcKEb5xGBSFu6kO0cBu1d73bixONq0fg%3D&amp;reserved=0