Subject: [Sidrops] three 8210bis issues

From: Randy Bush <[email-masked]>, Oliver Borchert <[email-masked]>
Date: Mon, 06 Dec 2021 18:30:35 -0800

we had a chat about the ASPA PDU in draft-ietf-sidrops-8210bis.  this is
not a vote or opinion poll.  but we would deeply appreciate new and
different insights, simply stated.

three issues, two minor or cosmetic, one substantial.  saving the
substantial for last.

0 - currently the AFI is a bit in the Flags field.  in ROA PDUs, IPv4
    and IPv6 are two different PDU Types.

    one suggestion is to do the same, an IPv4 ASPA PDU and an IPv6 PDU.

    another is to move the AFI bit out of the Flags field into the
    currently MBZ field following it.

    a separate idea is to have two bits in Flags or the following MBZ.
    but what to do when both are zero, yucchhh?

    pending further insight, -04 does not change this for the moment.

1 - currently, an ASPA Withdraw PDU is mandated to have at least one
    Provider AS.  but, as the purpose of the Withdraw is to completely
    remove the ASPA for that Customer from the router, why insist that
    the RP cache be able to exactly reproduce the Announce PDU in order
    to withdraw it?

    if 2, below, does not result in a change, one alternative is to
    mandate that the Withdraw ASPA PDU have zero Provider ASs, and that
    it removes all Providers for that single Customer.

    another approach, still assuming 2 below does not change, is to
    simply not flag Announce/Withdraw, and an ASPA PDU with no Providers
    is an implicit withdraw of all Providers for that Customer.

    pending further insight, -04 has the last alternative for the
    moment.

2 - the ROA PDUs are sent one Prefix/AS tuple at a time.  currently, the
    ASPA PDU groups all Providers into one tuple for the single
    Customer.

    the intuition was that ASPA is a one to many mapping while ROAs are
    one to one mappings.  but the result is different program flows on
    both ends of the protocol.

    for an ASPA PDU, currently the cache and router need not worry what
    the other thinks; a new ASPA is an implicit withdraw of the previous
    ASPA data in the router.  this is in contrast to ROAs and Router Key
    PDUs, where the cache and router must be aware of the other's state,
    and if discovered to be out of sync, a reset MUST be performed.

    -04 does not change this for the moment.  more insight is needed.
    it would be especially good to hear from more router side folk.

thanks.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 7 Dec 2021 10:14:10 +0100

Hi Randy, all,

in-line..

Generally speaking though, I think we need closure on the ASPA profile
changes as proposed and discussed. Ben Maddison raised questions on
November 11 (Re: [Sidrops] Experimental ASPA object published in testbed).

> On 7 Dec 2021, at 03:30, Randy Bush <[email-masked]> wrote:
> 

Note that there is also a proposal to have both v4 and v6 providers on
a single ASPA object. I think the cache can handle splitting this into
separate PDUs, but it may benefit from some text.

An alternative that I can think of is that there would be three length
fields. One for v4+v6, one for v4 only, one for v6. Any of which can
have length 0. Then a single PDU can contain the same data as a single
ASPA object, with a total combined length of 0 implying a withdraw
(see below).

I don't have any very strong preference in the matter, except to point
out that we need to be sure that the ASPA profile and this -bis are in
agreement.

>    pending further insight, -04 has the last alternative for the

This alternative works for me as long as we stick to the full providers
approach.

But...

There was a proposal to have an explicitly signed empty list of providers,
rather than overloading AS0 to mean no (valid) providers. 

I think we need closure on this in the ASPA profile because it may have
a bearing on this -bis.

If the ASPA profile -07 were to go for empty provider list rather than
AS0, then an explicit empty list PDU would be needed and it would not
be a withdraw. I.e. we would need to flag 'no ASPA for customer ASN' vs
'no providers for customer ASN'.

Because I did not wish to complicate the validation and rtr (this -bis),
I therefore came back on my earlier viewpoint on this, and suggested that
we do stick to AS0.

Can we conclude that the ASPA profile will keep AS0 and a minimal length
of 1 provider?

>    it would be especially good to hear from more router side folk.

I somewhat dislike it being inconsistent with how ROA VRPs are treated.
I also dislike that it could result in long PDUs being resent - the
current limit is 64k providers.. in practice I don't expect to see that
much, but the protocol allows it. I don't think this would impact the
RTR server much, but it could impact routers.

All that said, to me the most important point is that this gets input
as you are asking as well. I can have peace with either as long as that
has happened.

Thanks for raising this Randy,

Tim

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

---

From: Randy Bush <[email-masked]>
Date: Tue, 07 Dec 2021 10:08:06 -0800

tim,

[ excuse my loss of humor.  but some of this is getting old ]

> changes as proposed and discussed.

only if they affect the wire between cache and router

> a single ASPA object.

as the two AFIs have very different topologies, i assume this is just
noise and people will get over it.

> ASPA object, with a total combined length of 0 implying a withdraw

welcome to the ietf, where we take something simple and make it much
more complex.  why don't we merge the ROA AFIs too?  sheesh!

> There was a proposal to have an explicitly signed empty list of
> providers, rather than overloading AS0 to mean no (valid) providers.

which is what -04 says.  overloading magic values has a long unhappy
history in software engineering.  if folk really want to do this, i
propose AS17, or maybe AS666.

> 'no providers for customer ASN'.

you may want to actually look at -04

and, btw, as in previous discussion, what the RP receives from the
global rpki need not be what the RP sends to the router.  so it can
receive some kinky signal such as AS17 and send a null list to the
router.

> Can we conclude that the ASPA profile will keep AS0 and a minimal length

while i do not think that is useful or wise, this draft is not the place
to discuss it, see my previous paragraph.

> RTR server much, but it could impact routers.

ok, i will put on my vendor hat.

    part of the discussion oliver and i had is the unfortunate reality
    that there are ops with deployed routers which do not have the
    resources to buffer an entire rpki-rtr session and then process only
    once the End of Data PDU is received.  and the size of a full fresh
    rpki-rtr data set is growing.  so it would be extremely anti-pola to
    retroactively require this.

    if the cache sends cust/provider tuples for cust AS42 one at a time
    to the router, as each one arrives, does the router need to sweep
    all paths to revalidate?  how does it know it has the full provider
    set?  ...

as i tried to hint, i would really like to hear from [other] router
vendors on this.

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 8 Dec 2021 11:42:14 +0100

randy

> On 7 Dec 2021, at 19:08, Randy Bush <[email-masked]> wrote:
> 
> tim,
> 

Funny you should say that. It's my sense of humor that allows me
to continue to participate in this working group despite the loss
of humor in responses I get. I know that many have already given
up.

> only if they affect the wire between cache and router

That is indeed what I meant as well, so we are in agreement here.

> noise and people will get over it.

It would be helpful to make comments on that matter then when and
where it is discussed. I would be hesitant to make assumptions in
a last call.

> more complex.  why don't we merge the ROA AFIs too?  sheesh!

Indeed welcome to the IETF:
https://en.wikipedia.org/wiki/Reductio_ad_absurdum

> propose AS17, or maybe AS666.

Which -04? draft-ietf-sidrops-8210bis-04?

The current relevant counterparts to this document are:
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-profile-06
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-08

The verification document which relies on the information communicated
through RTR from this -bis says in section 6:

   Specifically, AS 0 is reserved to identify provider-free networks

Furthermore, the downstream paths section (5.2) relies on the presence
of an INVALID pair to decide where to switch from upstream to downstream:

   The first unequal of AS_SEQUENCE segments that has an "Invalid" outcome
   of the customer-provider verification procedure indicates the end of the
   Upstream fragment.

If an 'empty set' is to be used instead then this would need to be flagged
explicitly. Normally the empty set would result in "Unknown", so switching
the path verification direction on the first "Unknown" would not work.

> receive some kinky signal such as AS17 and send a null list to the

Assuming that things are changed and an explicit empty set is used
instead of AS0.. then we will need support to flag the difference
between a 'null' list (as you seem to say now) and no list.

Section 5.12 of draft-ietf-sidrops-8210bis-04 ends with:

   Receipt of an ASPA PDU with zero providers is an implicit withdraw
   of the entire ASPA data for that customer AS from that cache.

In other words this is indistinguishable from the case where no ASPA
object exists for that customer AS.

Perhaps this is not what you meant to say. Perhaps you meant to say
that this explicitly indicates "no providers exist for this customer
AS" - i.e. it's a null list, and that one should use a withdraw PDU
instead to say "no ASPA information exists for this customer AS" - i.e.
it's the absence of a list. If this is the case, then I think that
last sentence of 5.12 should be changed to clarify this.

That could work.. but then the aspa-verification section 5.2 would have
to be modified. Where it now says:

   The first unequal pair of AS_SEQUENCE segments that has an "Invalid"
   outcome of the customer-provider verification procedure indicates the
   end of the Upstream fragment.

It should then get something like:

   The first unequal pair of AS_SEQUENCE segments that has a null list
   of providers for the customer in the outcome of the customer-provider
   verification procedure indicates the end of the Upstream fragment.

And then the 'null list' customer-provider outcome would need to be
defined in section 4. I think that this may also be more clear than
overloading 'invalid'.

I am not opposed to this direction, but that text does not exist yet,
and I think it's unsafe to assume that it does - until it does..

> to discuss it, see my previous paragraph.

The reason it's relevant is that this RTR protocol needs to be capable of
communicating the information encoded in aspa-profile and used by
aspa-verification. If you don't want to discuss it here, then sure.. but
it needs to be resolved before last call of this -bis can be concluded.
Otherwise you make assumptions about the final outcome of those documents,
which may not be true - and the 8210-bis RFC may then not be suitable for
use with those documents..

---

From: Randy Bush <[email-masked]>
Date: Wed, 08 Dec 2021 06:30:45 -0800

sidrops chairs,

tim's right on at least two counts

  i need to keep my sense of humor; but you can't do much about that

  8210bis really can not advance with an ASPA PDU while ASPA itself
  is still wobbly

i request pulling 8210bis out of wglc

randy

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 8 Dec 2021 12:36:20 -0500

>   i need to keep my sense of humor; but you can't do much about that
A reminder to everyone: (I didn't want to say this N times in the thread)
  "please remember we (all of us) are here trying to make the internet
safer/better.
   people aren't actually trying to torpedo you/your-ideas/etc, we (all of
us) are trying
   to work through possible problems/solutions in an effort to 'make the
internet safer/better'"

So, with that in mind, please remember that before hitting 'send' we (all
of us) need to
verify that we are talking about the problems/solutions in the proposal and
not upset about
how our coffee is not hot right now :( (I need better coffee)

> i request pulling 8210bis out of wglc
This makes sense to me, sadly for the document, but happily for the
discussion and the process/end-result
which I hope will be better once we finish sorting out ASPA docs.

pending other WG-Chair comments, we can do this in the next short while.

-chris

---

From: Randy Bush <[email-masked]>
Date: Wed, 08 Dec 2021 09:50:41 -0800

> discussion and the process/end-result which I hope will be better once
> we finish sorting out ASPA docs.

as there are other somewhat imortant changes to the protocol in the
document, i considered just pulling out the ASPA bit.  but maybe we
give the ASPA docs another bit of time before giving up.

thanks.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 8 Dec 2021 12:56:20 -0500

> give the ASPA docs another bit of time before giving up.
that seems reasonable to me, yes.