[Sidrops] Remove AFI from ASPA in draft-ietf-sidrops-8210bis-10

[Claudio Jeker <[e-mail]>]

Hi,

To remove AFI from ASPA draft-ietf-sidrops-8210bis-10 needs to be
modified.  I think there was already a group consensus that the
version for this new draft shall remain at 2.

>From my understanding there is OpenBGPD and NIST-BGP-SRx that
implement 8210bis on the router side and StayRTR is the only cache which
released a version with 8210bis support.

My goal is to give the few OpenBGPD users which deployed ASPA a transition
path and period where old AFI specifc formats are still supported but the
AFI is simply ignored. At a later time those old formats will be removed
and result in errors. This would allow users to update their
infrastructure by updating OpenBGPD first and then the RTR cache and
finally the RP software.

For RTR the ASPA PDU needs to be adjusted. The simplest option here is to
just change the current 'AFI flags' field to zero. For 8210bis-10 speakers
this results in an IPv4 only table (AFI flag 0 == IPv4, 1 == IPv6).

The result of minimaly adjusting draft-ietf-sidrops-8210bis-10 Section 5.12
would look like this:

--------
    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 Numbers     ~
    |                                           |
    ~-------------------------------------------~

    The ASPA PDU supports [I-D.ietf-sidrops-aspa-profile]. An ASPA PDU
    represents one single customer AS and its provider ASes. Receipt
    of an ASPA PDU announcement (announce/withdraw flag == 1) when the
    router already has an ASPA PDU with the same Customer Autonomous
    System Number, replaces the previous one. The cache MUST deliver
    the complete data of an ASPA record in a single ASPA PDU.

    The Flags field is as described in Section 5. For the ASPA PDU, the
    announce/withdraw Flag is set to 1 to indicate either the announcement
    of a new ASPA record or a replacement for a previously announced
    record with the same Customer Autonomous System Number.

    If the announce/withdraw flag is set to 0, it indicates removal of
    the entire ASPA record for the specified Customer AS. Here, the
    customer AS of the ASPA record MUST be provided, the Provider AS
    Count must be zero, the Provider AS Numbers list MUST be null, and
    these last two fields MUST be ignored by the router.

    The Provider AS Count is the number of 32-bit Provider Autonomous
    System Numbers in the PDU. The Customer Autonomous System Number
    is the 32-bit Autonomous System Number of the customer which
    authenticated the ASPA RPKI data.
    There MUST be one and only one ASPA for a Customer Autonomous System
    Number active in the router at any time.

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

--------

The main benefit of this change is that the messages are still valid for
a draft-10 router. The problem is that the IPv6 data is missing and so
all IPv6 paths for published CAS are marked as invalid on these routers
(so operators need to disable ASPA validation for IPv6).

On top of this I'm not super happy with the text. For a start:
    ... the Provider AS Count must be zero, the Provider AS Numbers
    list MUST be null, and these last two fields MUST be ignored by
    the router.

It is bad practice when systems are required to accept what is considered
a malformed packet. Also what about length checks? In our codebase the
'Provider AS Count' is validated against the PDU length field and an error
is returned if it is not consitent. Now that check (while sensible)
violates the above. What about ASPA PDUs that are not a multiple of
4 bytes?

Section 5.12 also does not specify how a router should act if the PDU
length field and the Provider AS Count are not in sync. Are routers
required to accept trailing garbage? What about cases where the count
overflows the provided PDU?

In short I think the text of Section 5.12 needs additional clarifications
to address the above issues.


So what other options do we have?

There was the suggestion to remove Provider AS Count and move the Flags
up to the header like it is done for the Router Key PDU:

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

If we go this route the upgrade path between draft-10 and this new version
is more tricky but still doable since a session will be either following
old -10 or new -11 encoding and the first ASPA PDU is an announcement and
Flags == 1 in that case (using this info the system can check the new Flags
field as an indicator).
So the Router can detect the version of the draft used by the Cache and act
accordingly. This only works if the Routers are updated before the Caches.

Moving to this format has the benefit that there is no more conflict between
PAS count and PDU length possible. In an update the number of PAS is the
Length - 12 while a withdrawl would be just 12 bytes and carry no PAS
numbers.

Right now I prefer this option. While harder the implement the code
responsible to transition it will result in an overall better and simpler
end result.

I would like to know if this second approach to change the ASPA PDU
is generally accepted by this group so that I can help updating the draft
accordingly. I would also adjust OpenBGPD to follow this path so that we
can start the transition.

Regards
-- 
:wq Claudio