Subject: [Sidrops] 8210bis

From: Randy Bush <[email-masked]>
Date: Thu, 06 Feb 2020 19:11:25 -0800

we're working on 8210bis, The Resource Public Key Infrastructure (RPKI)
to Router Protocol, Version 2

   1.2.  Changes from RFC 8210

   This section summarizes the significant changes between [RFC6810] and
   the protocol described in this document.

   o  New ASPA PDU type (Section 5.12) added to support
      [I-D.ietf-sidrops-aspa-profile].

   o  Protocol version number incremented from 1 (one) to 2 (two).

while we're doing the ASPA PDU hack, do any implementors of 6810/8210
have comments based on experience implementing 6810/8210?

randy

---

From: Martin Hoffmann <[email-masked]>
Date: Sat, 8 Feb 2020 10:37:10 +0100

> have comments based on experience implementing 6810/8210?

The one thing that tripped me up when implementing RTR was that the
content of the End-of-data PDU had changed between versions 0 and 1 and
this isn’t properly mentioned in 8210 (there’s a vague note in section
1.2 that one can really only interpret correctly in hindsight). Since
the old format isn’t mentioned but in practice you will have to
implement version 0, you need to read and implement an obsoleted RFC
which seems a bit wrong to me.

It would be good if 8210bis would at least stick a big warning at its
equivalent to section 5.8 or, better yet, show the format for version
0 as well.

The other thing that is a bit iffy when implementing is that for the
Router Key PDU the flags field is moved from the payload into to the
header repurposing part of what is the session ID when present. Maybe
for the ASPA PDU you could keep it in the payload?

Kind regards,
Martin

---

From: Randy Bush <[email-masked]>
Date: Sat, 08 Feb 2020 19:19:07 -0800

>> have comments based on experience implementing 6810/8210?

your comments really appreciated

> equivalent to section 5.8 or, better yet, show the format for version

both done.

> header repurposing part of what is the session ID when present.

yuchhh!  <blush>

> Maybe for the ASPA PDU you could keep it in the payload?

5.12.  ASPA PDU

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

   The ASPA PDU is to support [I-D.ietf-sidrops-aspa-profile].

   The lowest-order bit of the Flags field is 1 for an announcement and
   0 for a withdrawal.  Withdrawal of a non-existant or non-matching
   ASPA PDU is an error.

   The Provider AS Count is the number of 32-bit Provider Autonomous
   System Numbers in the PDU.  There may be none.

   The Customer Autonomous System Number is the 32-bit Autonomous System
   Number of the customer which signed the PDU.  There may be only one
   ASPA for a Customer Autonomous System Number active at any time.

   There are zero or more 32-bit Provider Autonomous System Number
   fields; see [I-D.ietf-sidrops-aspa-profile].

---

From: Randy Bush <[email-masked]>
Date: Sat, 08 Feb 2020 19:32:48 -0800

and implementor feedback on this would be appreciated

   The ASPA PDU is to support [I-D.ietf-sidrops-aspa-profile].  Receipt
   of an ASPA PDU announcement when the router already has an ASPA PDU
   with the same Customer Autonomous System Number, replaces the
   previous one.  This is to avoid surprises when a BGP announcement is
   received between an withdrawn PDU and a new announced PDU.

randy

---

From: Martin Hoffmann <[email-masked]>
Date: Sun, 9 Feb 2020 06:51:40 +0100

>    fields; see [I-D.ietf-sidrops-aspa-profile].

As a mere implementer, I can’t really judge how many Provider ASNs a
single ASPA typically will have, so I am just throwing this out there
for consideration:

ROAs are decomposed into a separate PDU for each prefix. The advantage
is that the PDUs are fixed size and I can keep read buffers on the
stack, whereas for variable length PDUs I will have to have some kind of
allocation strategy. Obviously, there is a 96 byte overhead for each
additional Provider ASN if we did the same for ASPAs. 

Am I assuming correctly that decomposing the ASPA would also make the

Kind regards,
Martin