Subject: Re: [Sidrops] New Version Notification for draft-ymbk-8210bis-00.txt

From: Martin Hoffmann <[email-masked]>
Date: Fri, 6 Mar 2020 13:01:29 +0100

Randy Bush wrote:
> A new version of I-D, draft-ymbk-8210bis-00.txt has been successfully
> submitted by Randy Bush and posted to the IETF repository.

I’d like to bring up my earlier proposal to exchange the ASPA contents
as pairs rather than lists again. In this case, the ASPA Payload would
look like this:

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

Much like all the prefixes on a ROA, there would be one ASPA Payload PDU
for each provider ASN in the ASPA RPKI object.

The main reason for proposing this is that this will bring handling of
ASPA PDUs in line with all the other payload PDUs in that the combined
payload is treated as a set: Each payload unit forms its own key for
lookups. Which is what makes the current announce/withdraw model work.

The ASPA PDU proposed in the draft works like a map: The key is the
customer ASN and the list of provider ASNs is the value.

Having two different ways of dealing with payload increases complexity,
both in the standard and in the implementations.

Splitting up the ASPA RPKI object would increase the overall size of the
response to a RTR reset query, but on the other hand decreases the
overall size of serial queries. Given that RTR sessions are very
long-lived, I think (without any actual evidence), that there might
even be an overall advantage in data size.

                                  *   *   *

As a separate note, ASPA in its current form includes the address
family, ie., it has different ASPA objects for v4 and v6. This is
missing from the proposed ASPA RTR payload PDU, but luckily there is
enough zero space to include it.

Kind regards,
Martin

---

From: Randy Bush <[email-masked]>
Date: Fri, 06 Mar 2020 13:15:24 -0800

> ASPA in its current form includes the address family, ie., it has
> different ASPA objects for v4 and v6. This is missing from the
> proposed ASPA RTR payload PDU, but luckily there is enough zero space
> to include it.

a point to be settled between aspa and rpk-rtrv2.  do we really see
significant divergence between ipv4 and ipv6 topologies?  if so, is
this a good thing which should be supported at the cost of two tables
in the router?

thanks for raising the issue.

randy

---

From: Randy Bush <[email-masked]>
Date: Mon, 09 Mar 2020 20:21:51 -0700

> enough zero space to include it.

i believe this is addressed in the draft out today; though not exactly
in the way you suggest.  thanks again for pointing this out.

randy

---

From: Alexander Azimov <[email-masked]>
Date: Sat, 21 Mar 2020 22:14:13 +0300

The separated records for v4 and v6 ASPA were inspired by the previous
research that showed a significant difference in the peering relations in
v4 and v6 respectively.
I did this research a couple of years ago, it will be interesting to check
if the situation has significantly changed.

I'd like to get the WG attention on the introduced update of ROA processing.
The current version of the RTR protocol related to ROAs is vulnerable to
possible race conditions: if the prefix has multiple ROA records or it
covering prefixes with different origin asn the state of the partial update
may lead to invalidating of really valid prefixes. Here is fresh statistics:

   - 16153 IPv4 prefixes with equal (5486) or more specific (11872)
   conflicts;
   - 2250 IPv6 prefixes with equal (1202) or more specific (1164) conflicts.

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.

вт, 10 мар. 2020 г. в 06:22, Randy Bush <[email-masked]>:

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

-- 
Best regards,
Alexander Azimov

---

From: Martin Hoffmann <[email-masked]>
Date: Tue, 24 Mar 2020 12:25:34 +0100

Alexander Azimov wrote:
> 
> I'd like to get the WG attention on the introduced update of ROA
> processing. The current version of the RTR protocol related to ROAs
> is vulnerable to possible race conditions: if the prefix has multiple
> ROA records or it covering prefixes with different origin asn the
> state of the partial update may lead to invalidating of really valid
> prefixes.

Can you elaborate a bit more on this issue? The only scenario I can
think of is that diffs are not applied atomically by clients which feels
to me like a bit of a bad implementation?

Kind regards,
Martin

---

From: Randy Bush <[email-masked]>
Date: Tue, 24 Mar 2020 12:02:10 -0700

> 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