Subject: [Sidrops] Fw: New Version Notification for draft-ietf-sidrops-roa-considerations-01.txt

From: "YAN Zhiwei" <[email-masked]>
Date: Wed, 27 Oct 2021 09:48:24 +0800

Hi, all,
The following draft was updated.
In this version, we made some analysis of the current ROA data.
Any comments are welcome.
Thanks,
BR,

YAN Zhiwei
 
From: internet-drafts
Date: 2021-10-26 22:11
To: Guanggang Geng; Jiankang Yao; Randy Bush; Zhiwei Yan
Subject: New Version Notification for draft-ietf-sidrops-roa-considerations-01.txt
 
A new version of I-D, draft-ietf-sidrops-roa-considerations-01.txt
has been successfully submitted by Jiankang Yao and posted to the
IETF repository.
 
Name: draft-ietf-sidrops-roa-considerations
Revision: 01
Title: Problem Statement and Considerations for ROA containing Multiple Prefixes
Document date: 2021-10-25
Group: sidrops
Pages: 9
URL:            https://www.ietf.org/archive/id/draft-ietf-sidrops-roa-considerations-01.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-sidrops-roa-considerations/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-roa-considerations
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-roa-considerations-01
 
Abstract:
   The address space holder needs to issue an ROA object when it
   authorizes one or more ASes to originate routes to IP prefix(es).
   During the process of ROA issuance, the address space holder may need
   to specify an origin AS for a list of IP prefixes.  Besides, the
   address space holder has a free choice to put multiple prefixes into
   a single ROA or issue separate ROAs for each prefix based on the
   current specification.  This memo analyzes and presents some
   operational problems which may be caused by the ROAs containing
   multiple IP prefixes.  Some suggestions and considerations also have
   been proposed.

 
The IETF Secretariat

---

From: Ties de Kock <[email-masked]>
Date: Wed, 27 Oct 2021 10:35:33 +0200

Hi,

> On 27 Oct 2021, at 03:48, YAN Zhiwei <[email-masked]> wrote:
> 
> Hi, all,

In the draft I read:

>   The potential influence of operations of ROAs containing multiple IP
>   prefixes on BGP routers must be considered.  For the ROA containing
>   multiple prefixes, once increase or delete one <AS, ip_prefix> pair
>   in it, this whole ROA must be withdrawn and reissued.  Through
>   sychronization with repository, Relying Party (RP) fetches a new ROA
>   object and then notify and send all the <AS, ip_prefix> pairs in this
>   ROA to BGP routers.  That is to say, the update of the ROA containing
>   multiple IP address prefixes will lead to redundant transmission
>   between RP and BGP routers.  So frequent update of these ROAs will
>   increase the convergency time of BGP routers and reduce their
>   performance obviously.

Could you elaborate on the testing setup in which you observed this situation?

Because I would consider it a bug if a single prefix being removed caused all
VRPs on the ROA to be withdrawn and then announced again over RTR. I decided to
try to replicate this and I could not.

What I do observed was:
  * (initial situation): A CA with one ROA with many prefixes for a specific AS
    on an internal test environment for RIPE NCC RPKI dashboard.
    * The CA has roa for that AS with many prefixes in it.
  * (user): Deletes one prefix for that AS from the CA.
  * (system): re-creates the ROA (file), new ROA replaces old one
  * (system): ROA replaces (publish w/ hash for RRDP, in rsync the file changes) the old ROA file
  * (rp): fetches new file, calculates new VRPs
  * (rp): sends a PDU for a single prefix, flags indicate it is a withdraw

In my opinion, if a RP or CA causes all <AS, ip_prefix> pairs to be withdrawn
temporarily, it is a bug in the software stack. A CA can (and should) publish
this change without an intermediate state in which <AS, ip_prefix> pairs
disappear.

Kind regards,
Ties

p.s. The software I used was: Routinator 0.10.1, RIPE NCC CA software cb9e889f4, rpki-rtr-client, wireshark

> 
> YAN Zhiwei
>  
> From: internet-drafts <mailto:[email-masked]>
> Date: 2021-10-26 22:11
> To: Guanggang Geng <mailto:[email-masked]>; Jiankang Yao <mailto:[email-masked]>; Randy Bush <mailto:[email-masked]>; Zhiwei Yan <mailto:[email-masked]>
> URL:            https://www.ietf.org/archive/id/draft-ietf-sidrops-roa-considerations-01.txt <https://www.ietf.org/archive/id/draft-ietf-sidrops-roa-considerations-01.txt>
> Status:         https://datatracker.ietf.org/doc/draft-ietf-sidrops-roa-considerations/ <https://datatracker.ietf.org/doc/draft-ietf-sidrops-roa-considerations/>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-roa-considerations <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-roa-considerations>
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-roa-considerations-01 <https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-roa-considerations-01>
>  
> Abstract:
> _______________________________________________
> Sidrops mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sidrops <https://www.ietf.org/mailman/listinfo/sidrops>

---

From: Randy Bush <[email-masked]>
Date: Wed, 27 Oct 2021 19:12:14 -0700

> Because I would consider it a bug if a single prefix being removed
> caused all VRPs on the ROA to be withdrawn and then announced again
> over RTR.

as it is within the specs, it depends on the implementation of the CA,
the PP, and the RP.  have fun setting up the NxMxL experiment :)

>   * (system): re-creates the ROA (file), new ROA replaces old one

does the publication protocol have a Replace operation?  i do not
remember it.  if not, it's either a create and a delete or a delete and
a create.  my memory is that ordering is not discussed.

and things go wobbly from there.

> In my opinion, if a RP or CA causes all <AS, ip_prefix> pairs to be
> withdrawn temporarily, it is a bug in the software stack.

bug in what sense?  protocol/rfc violation or just the normal ill
advised coding?

> A CA can (and should) publish this change without an intermediate
> state in which <AS, ip_prefix> pairs disappear.

but it might not.  luckily we have not seen questionalble programming
practice in rpki implementations </dripping sarcasm>

> cb9e889f4, rpki-rtr-client, wireshark

thanks for actually describing your experimental setup.  i wish we all
were good about this.

for me, the goal here is simplicity.  to quote a friend with whom i
agree

    I seem to remember you (Randy) jumping up and down about how
    operators don't give a rat's <bleep> about the AS number per se,
    it's just a tool: operators think about this in terms of prefixes,
    and what operators care about are the prefixes, so arbitrarily
    stuffing a bunch of prefixes into a single object is premature
    optimization at the expense of simplicity and fate sharing.

    I think the original motivation was just trying to squeeze out as
    many bits as possible, on the theory that ROAs might end up being
    flooded inline via BGP, in much the same spirit as the bizarre
    encoding of prefixes as bit strings in RFC 3779.  Once inline BGP
    flooding was off the table, size became relatively unimportant (RPKI
    objects are tiny compared to the average kitten video), so
    operational fate sharing and user interface simplicity seemed like
    more pressing issues.

    Of course, no bad idea ever dies, so there are people whining about
    wanting to stuff RPKI into inline BGP again....

as to that latter, have we learned nothing about overly tight coupling
and interdependence from facebook?  the lesson there is nothing new,
just shoved in the world's face.  privacy and security are not the same
since snowden.  wrapping things in a tightly over-bound harball should
not be the same since facebook.  but i digress.

randy

---

From: Ties de Kock <[email-masked]>
Date: Thu, 28 Oct 2021 09:20:31 +0200

Hi Randy,

> On 28 Oct 2021, at 04:12, Randy Bush <[email-masked]> wrote:
> 

Indeed, the number of permutations is not pretty. Since you need a consistent
set of objects for the RP to accept the content of a PP, I would focus on the CA
and RTR implementation when setting up the experiment.

> and things go wobbly from there.

"publish with a hash", mismatching hash results in an error (rfc8181 2.2). In
practice, an implementation needs to abort the whole operation if an error
occurs (iirc [1] does). Otherwise, updating a single object for a CA would
almost always [2] result in a consistency problem.

I agree that ordering is under-specified in 8181.
> bug in what sense?  protocol/rfc violation or just the normal ill

That depends on where it happens - and I had to look it up. If this happens in
an RTR pdu, I think this is a protocol violation since this is not the minimal
set of changes (rfc8210 5.3).

> practice in rpki implementations </dripping sarcasm>

It might not. But in that case, it would publish an intermediate state that does
not reflect the intent of the human operating the CA. Again, bug.

> not be the same since facebook.  but i digress.

As a CA operator, "one prefix per ROA" is not simpler (and would cause ~5x more
objects to sign, transfer, and serve). I don't think this should be blanket
advice; it is a trade-off between failure modes (e.g. fate-sharing vs ROAs
expiring at a different time). The elephant in the room is fate-sharing at the
CA level and the brittleness that fate sharing by manifest lifetime introduces.

If routers frequently encounter the mass withdrawal + publication described, a
single prefix per roa may be a good workaround for that bug, and I would support
that if needed. Clarification from the authors on the situation where this
behaviour was encountered would help. 

Kind regards,
Ties

[1] https://github.com/RIPE-NCC/rpki-publication-server
[2] the exception that I can think of is the CA certificate signed by a TAL's public key
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: "YAN Zhiwei" <[email-masked]>
Date: Fri, 29 Oct 2021 10:00:56 +0800

Hello, Ties,
RPKI RFCs specify the communication protocols between different entities (CA, PP, RP, BGP-Router…) and the format of objects. However, different implementations have different understanding and design logic during the operation. Then how to handle multiple prefixes under the same AS may different. 
As I tested using DRL-CA software with the following 4 stages:

1. Initial stage
# cat load_roa_requests test.csv
1.1.1.0/24-24 10000 24
2.2.2.0/24-24 10000 24
#rpkic -i test load_roa_requests test.csv

The ROA content is:
ROA Version:    0
SigningTime:    2021-10-28T06:43:33Z
asID:           10000
addressFamily: 1
     IPAddress: 1.1.1.0/24
     IPAddress: 2.2.2.0/24

2. Delete a prefix
# cat load_roa_requests test.csv
1.1.1.0/24-24 10000 24

#rpkic -i test load_roa_requests test.csv

The ROA content is:
ROA Version:    0
SigningTime:    2021-10-28T06:44:26Z
asID:           10000
addressFamily: 1
     IPAddress: 1.1.1.0/24

3. Increase a prefix
# cat load_roa_requests test.csv
1.1.1.0/24-24 10000 24
2.2.2.0/24-24 10000 24

#rpkic -i test load_roa_requests test.csv

The ROA content is:
ROA Version:    0
SigningTime:    2021-10-28T06:45:40Z
asID:           10000
addressFamily: 1
     IPAddress: 1.1.1.0/24
     IPAddress: 2.2.2.0/24

4. re-load
# cat load_roa_requests test.csv
1.1.1.0/24-24 10000 24
2.2.2.0/24-24 10000 24

#rpkic -i test load_roa_requests test.csv

The ROA content is:
ROA Version:    0
SigningTime:    2021-10-28T06:45:40Z
asID:           10000
addressFamily: 1
     IPAddress: 1.1.1.0/24
     IPAddress: 2.2.2.0/24

It shows that:
1. Increase or delete the prefix within one ROA will cause the re-issue of the ROA (both the time and file name changed). This update of ROA will looks like a new one for the PP and RP. Then the CA revokes the old one. And accordingly the RP needs to synchronize the data. (Maybe the description in the draft is not accurate enough. It's appeciate if you can suggest the descriptions.)
2. While, re-load will not cause any change of the ROA file because the software will compare the data in the csv file.

ps. Here I am not saying DRL-CA has shortcoming.
BR,

YAN Zhiwei
 
From: Ties de Kock
Date: 2021-10-28 15:20
To: Randy Bush
CC: sidrops
Subject: Re: [Sidrops] New Version Notification for draft-ietf-sidrops-roa-considerations-01.txt
Hi Randy,

 

 

 

 
Kind regards,
Ties