search

NICMx / FORT-validator

RPKI cache validator
MIT License
50 stars 24 forks source link

fort does not update the ROA with the specified interval #92

Closed jimmymcheung closed 1 year ago

jimmymcheung commented 1 year ago

I'm running for 1.5.4 with --mode server and connected to a bird 2.0.12 daemon. At both end I have set a

retry    90
refresh  900
expire   86400

and additionally with fort I've set --server.interval.validation 3600. However, I can see the last ROA update the bird has received remains at the day when the connection is built (March 16 compare to March 25 = today). Bird only gets new update if I restart the fort completely (so just start a new fort with the old one killed).

Can anyone verify if there's a bug that preventing it provide ROA updates to bird?

ydahhrk commented 1 year ago

I can see the last ROA update the bird has received remains at the day when the connection is built

Ok, but how? How are you checking the update date?

Assuming it's from show route table, I couldn't reproduce the problem in my first attempt. I got most of my ROAs on my first batch:

$ sudo birdc show route table r4
BIRD 2.0.7 ready.
Table r4:
201.122.17.0/24-24 AS8151  [fort 15:59:26.414] * (100)
45.185.184.0/23-24 AS269807  [fort 15:59:27.411] * (100)
189.84.120.0/24-24 AS28368  [fort 15:59:27.457] * (100)
190.216.18.0/24-24 AS20207  [fort 15:59:27.087] * (100)
190.90.48.0/22-24 AS27837  [fort 15:59:26.675] * (100)
200.10.202.0/24-24 AS3597  [fort 15:59:26.819] * (100)
190.131.194.0/24-24 AS262191  [fort 15:59:26.819] * (100)
170.247.208.0/22-22 AS265229  [fort 15:59:27.523] * (100)
...
...
...

But there are a few that were acquired one hour later:

$ sudo birdc show route table r4 | grep -v "fort 15"
BIRD 2.0.7 ready.
Table r4:
177.73.159.0/24-24 AS270105  [fort 16:58:32.387] * (100)
177.73.158.0/23-24 AS270105  [fort 16:58:32.387] * (100)
177.73.157.0/24-24 AS270105  [fort 16:58:32.387] * (100)
198.12.36.0/22-24 AS27988  [fort 16:58:32.387] * (100)

Admittedly, I got default configuration and

$ bird --version
BIRD version 2.0.7

Will compile the newer version and try your config, see if that changes anything.

ydahhrk commented 1 year ago

Unfortunately, I still can't reproduce this on 2.0.12:

$ tail -16 /usr/local/etc/bird.conf
roa4 table r4;
roa6 table r6;

protocol rpki {
        debug all;

        roa4 { table r4; };
        roa6 { table r6; };

        # Please, do not use rpki-validator.realmv6.org in production
        remote "xxxxxxxxxx" port 8323;

    retry    90;
    refresh  900;
    expire   86400;
}
$
$
$ sudo birdc show route table r4 | head -6
BIRD 2.0.12 ready.
Table r4:
201.122.17.0/24-24 AS8151  [rpki1 2023-03-30] * (100)
45.185.184.0/23-24 AS269807  [rpki1 2023-03-30] * (100)
190.216.18.0/24-24 AS20207  [rpki1 2023-03-30] * (100)
190.90.48.0/22-24 AS27837  [rpki1 2023-03-30] * (100)
$
$
$ sudo birdc show route table r4 | grep -v "rpki1 2023-03-30" | head -6
BIRD 2.0.12 ready.
Table r4:
45.177.18.0/24-24 AS267885  [rpki1 18:24:05.613] * (100)
45.177.19.0/24-24 AS267885  [rpki1 18:24:05.613] * (100)
45.177.16.0/22-22 AS267885  [rpki1 2023-03-31] * (100)
186.84.152.0/22-24 AS14080  [rpki1 03:17:33.774] * (100)
jimmymcheung commented 1 year ago

Sorry for the delay, I didn't get notified on this thread. I killed fort a serval times, and now after > half month running (since 04-21), it is getting some update var from 04-21 to yesterday. The older fort process which didn't get update has also high CPU usage (~100% constantly), so I guess there was a random bug which did not repeat itself.

The result brings another question, does the update reflects only the changes in the route object? Since I see the majority has its date value still being 2023-04-21 which is the date the fort was started, while only a few have newer dates (from 05-05 till 05-14).

ydahhrk commented 1 year ago

does the update reflects only the changes in the route object?

I don't think so, strictly speaking, but I suppose it depends on what you mean by "route object." I don't think any relevant standards define this term.

Fort summarizes the repository ROA "Signed Objects" into "validated prefix origin data", which is what it sends to Bird, and is the list Bird is printing.

Fort sends this data using a protocol named "RTR" (RFC8210). RTR is incremental; if your router already has an old version of the list, it only sends the deltas needed to convert it into the new version. This, I believe, is the reason why some of your records have different dates.

But, just to be clear, if a "record" doesn't change, it's not necessarily because the signed "object" didn't change. Suppose the repository contains ROA object 192.0.2.0/24 => AS1234, but then its expiration date changes. The object will be refreshed (ie. changed), but the record will stay the same. Because the record doesn't care where the ROA came from. Even if it changed owner, and it's found in a different repository publication point, as long as the 192.0.2.0/24 => AS1234 part of it stays the same, and the object validates properly, Fort will not bother the router with a delta.

jimmymcheung commented 1 year ago

By "route object" I mean ROA here. What I trying to ask was whether fort only update an already queried ROA when there's change on that ROA. But since you mentioned RTR is incremental, I suppose that's the reason I saw varying dates on the object.

Shall I also assume the fort is still scanning for new (change to) ROA at the predefined refresh intervals, and would only notify router to update upon changes found (like IXFR in DNS world)?

ydahhrk commented 1 year ago

Shall I also assume the fort is still scanning for new (change to) ROA at the predefined refresh intervals, and would only notify router to update upon changes found (like IXFR in DNS world)?

There's no notify, but other than that, it would seem RTR was directly inspired by IXFR. The "refresh" interval is server.interval.validation.

Protocol summary ("RP" is "Relying Party," ie. Fort):

Again, there's no notify, but at the end of every transfer, Fort suggests a next query timestamp (but only if RTRv1 was negotiated, not RTRv0).