[{"author": "Keyur Patel", "text": "

Hello Sidrops!!

", "time": "2024-03-19T05:30:39Z"}, {"author": "Joel Jaeggli", "text": "

in favor of more slots to do work / virtual interim

", "time": "2024-03-19T05:32:09Z"}, {"author": "Joel Jaeggli", "text": "

I currently have 22:30 start time

", "time": "2024-03-19T05:32:51Z"}, {"author": "Randy Bush", "text": "

@geoff you sound great at 22:30 :)

", "time": "2024-03-19T05:32:53Z"}, {"author": "Chris Morrow", "text": "

is 01:30...

", "time": "2024-03-19T05:33:05Z"}, {"author": "Joel Jaeggli", "text": "

which is less bad than 3am au

", "time": "2024-03-19T05:33:08Z"}, {"author": "Joel Jaeggli", "text": "

but yes

", "time": "2024-03-19T05:33:17Z"}, {"author": "Joel Jaeggli", "text": "

many people get to lose

", "time": "2024-03-19T05:33:24Z"}, {"author": "Chris Morrow", "text": "

(trying find a time is correctly bad for global :( )

", "time": "2024-03-19T05:33:28Z"}, {"author": "Maria Mat\u011bjka", "text": "

@meetecho camera on speaker please

", "time": "2024-03-19T05:39:25Z"}, {"author": "Maria Mat\u011bjka", "text": "

thanks!

", "time": "2024-03-19T05:39:40Z"}, {"author": "George Michaelson", "text": "

I think the point of substance would be can we stick to email asynchronous discussion for things

", "time": "2024-03-19T05:40:35Z"}, {"author": "George Michaelson", "text": "

and if not, what is the specific outcome of interim and f2f?

", "time": "2024-03-19T05:40:49Z"}, {"author": "Joel Jaeggli", "text": "

both deadlines which you can impose abritratily and high bandwidth engagemtn are demonstraboly more productive than isosyncrouns engagment

", "time": "2024-03-19T05:42:45Z"}, {"author": "Joel Jaeggli", "text": "

seems like sidrops does need more frequent high bandwidth engament however that is achieved

", "time": "2024-03-19T05:48:19Z"}, {"author": "Joel Jaeggli", "text": "

as evidenced by me and probably others tuning in about 3 times a a year

", "time": "2024-03-19T05:49:14Z"}, {"author": "Chris Morrow", "text": "

There's certainly been some consternation among implementers over a bunch of some core parts here.

", "time": "2024-03-19T05:52:21Z"}, {"author": "Randy Bush", "text": "

medium and large deployments have mixed RPs. if they behave differently, kaboom

", "time": "2024-03-19T05:54:43Z"}, {"author": "Chris Morrow", "text": "

still seems like you'd probably guard the 'new way' in a flag per RP software then roll that flag over as you finish up code deployments to the RPs in your world.

\n

it's not a global flag-day, but...

", "time": "2024-03-19T05:56:12Z"}, {"author": "Ties de Kock", "text": "

Behaviour will diverge between software versions (with/w/o the change). You will also hit this with a flag day (old version pre-behaviour, newer versions)

", "time": "2024-03-19T05:56:23Z"}, {"author": "George Michaelson", "text": "

so if we're defining BGP attributes to carry path, could we .. define BGP atributes to carry manifest, and ADD/DEL/UPD for ROA?

", "time": "2024-03-19T06:00:53Z"}, {"author": "Jeffrey Haas", "text": "

As best I understand Job's presentation, the flag day is somewhat squishy. If everyone is conformant to existing and stricter procedures, they're conformant to the new desired behavior. I also understand that the current behavior is generally how we want the records to be published.

\n

What he's describing is that when there's an error, he wants laxer behaviors; validation succeeds rather than fails. When the records are inconsistent, the likely desire is that the records are corrected. Meanwhile, you'll have a subset of the Internet using strict procedures that now are in a dire failing mode and a subset of the Internet using the newer lax procedures still working.

", "time": "2024-03-19T06:02:40Z"}, {"author": "Jeffrey Haas", "text": "

@Job Snijders do I have the scenario correct?

", "time": "2024-03-19T06:02:48Z"}, {"author": "zhang jun", "text": "

will you compare the performance of FC-BGP with ASPA?

", "time": "2024-03-19T06:04:27Z"}, {"author": "Job Snijders", "text": "

@Jeffrey Haas This global (and local) inconsistencies already are a part of life: not all network use the same TALs as other networks, not all networks use the same TALs inside their RPs, and not all RP implementations are compliant with the current standards in relationship to for example Manifest handling. So I don't think that redefining this specific algorithm adds much variance across the board: the errors I'm trying to address are transcient so its entirely possible that some RPs see the error case and some don't (with the current algorithm) depending on fetching / parsing timers

", "time": "2024-03-19T06:06:17Z"}, {"author": "Jeffrey Haas", "text": "

Job Snijders said:

\n
\n

Jeffrey Haas This global (and local) inconsistencies already are a part of life: not all network use the same TALs as other networks, not all networks use the same TALs inside their RPs, and not all RP implementations are compliant with the current standards in relationship to for example Manifest handling. So I don't think that redefining this specific algorithm adds much variance across the board: the errors I'm trying to address are transcient so its entirely possible that some RPs see the error case and some don't (with the current algorithm) depending on fetching / parsing timers

\n
\n

I agree with Rob that mixed mode deployment will lead to different behaviors. Your point is we have a flavor of this already. My point is that the desire is that when we deviate from the perfect, which will cause failures today, we move to the more relaxed. Thus, when the situation you're addressing occurs, the strict mode users are going to break... this already needs action to correct.

", "time": "2024-03-19T06:08:27Z"}, {"author": "Randy Bush", "text": "

could we not just have a little chat with arin?

", "time": "2024-03-19T06:13:30Z"}, {"author": "Joel Jaeggli", "text": "

sound have a little chat with arin

", "time": "2024-03-19T06:14:40Z"}, {"author": "Ties de Kock", "text": "

@Randy: This issue needs serious mis-issuance to have impact. Most likely cause - to me- would be loss of control of private key and an attempt to DOS the CA. Not sure why I would trust the CA afterwards.

", "time": "2024-03-19T06:15:00Z"}, {"author": "Ties de Kock", "text": "

*to have impact <=> to happen

", "time": "2024-03-19T06:15:14Z"}, {"author": "Zhuotao Liu", "text": "

zhang jun said:

\n
\n

will you compare the performance of FC-BGP with ASPA?

\n
\n

Good question! FC-BGP messages are real-time propagated via BGP routing protocol. So it does not add objects to RPKI. So it is hard to compare their performance Apple-to-apple. In terms of security, the two approaches have different goals but they can complement to each other. I am happy to discuss this more offline.

", "time": "2024-03-19T06:15:18Z"}, {"author": "Joel Jaeggli", "text": "

if someone upstream deaggragates you prefix for you that's invalid

", "time": "2024-03-19T06:17:22Z"}, {"author": "Joel Jaeggli", "text": "

yeah no, you claim matches the route announced or it does not

", "time": "2024-03-19T06:18:07Z"}, {"author": "Joel Jaeggli", "text": "

you don't jailhouse lawyer two more specifics into route you're willing to accept

", "time": "2024-03-19T06:18:53Z"}, {"author": "Jeffrey Haas", "text": "

Zhuotao Liu said:

\n
\n

zhang jun said:

\n
\n

will you compare the performance of FC-BGP with ASPA?

\n
\n

Good question! FC-BGP messages are real-time propagated via BGP routing protocol. So it does not add objects to RPKI. So it is hard to compare their performance Apple-to-apple. In terms of security, the two approaches have different goals but they can complement to each other. I am happy to discuss this more offline.

\n
\n

I owe the authors a thorough read of your fc-bgp draft. However, you have a SKI. Where is the key stored? I would have presumed something like RPKI.

", "time": "2024-03-19T06:23:59Z"}, {"author": "Zhuotao Liu", "text": "

Exactly! We rely on RPKI for that. My previous statement is we do not plan to consistently add new objects during path validation. But yes, we need a shared trust base like RPKI. I skip this in today\u2019s presentation due to time constraints

", "time": "2024-03-19T06:28:44Z"}, {"author": "Maria Mat\u011bjka", "text": "

i'm still completely clueless what to do with transparent route server setups which are completely incompatible with fc-bgp

", "time": "2024-03-19T06:31:11Z"}, {"author": "Jeffrey Haas", "text": "

Maria Mat\u011bjka said:

\n
\n

i'm still completely clueless what to do with transparent route server setups which are completely incompatible with fc-bgp

\n
\n

A procedure similar to RSes and bgpsec likely should be used.

", "time": "2024-03-19T06:32:06Z"}, {"author": "Jeffrey Haas", "text": "

For @Job Snijders 's presentation, RFC 8097 extended communities are non-transitive for the reasons mentioned in the presentation.

", "time": "2024-03-19T06:35:27Z"}, {"author": "Randy Bush", "text": "

8097 communities should be nuked from orbit

", "time": "2024-03-19T06:40:49Z"}, {"author": "Rob Austein", "text": "

@job re validation reconsidered: keep in mind that one of the implmenetations of the rfc3779 algorithm that needs to be updated is openssl itself. sorry, seemed like a good idea at the time.

", "time": "2024-03-19T06:42:20Z"}, {"author": "Ties de Kock", "text": "

@rob: I think that the generic interpretation of rfc3779 should not change. But within RPKI this looser definition seems to be less fragile to me.

", "time": "2024-03-19T06:43:14Z"}, {"author": "Rob Austein", "text": "

oh boy now we have application specific different interpretation of the same critical extension? whee!

", "time": "2024-03-19T06:43:56Z"}, {"author": "Ties de Kock", "text": "
\n

oh boy now we have application specific different interpretation of the same critical extension? whee!

\n
\n

because the only alternative is a flag day (or fragility that you hit depending on what order you observe states in in a distributed system)

", "time": "2024-03-19T06:45:19Z"}, {"author": "Jeffrey Haas", "text": "

Randy Bush said:

\n
\n

8097 communities should be nuked from orbit

\n
\n

Care to tersely expand on why?

", "time": "2024-03-19T06:45:23Z"}, {"author": "Job Snijders", "text": "

@Rob Austein current plan is to introduce a new flag for X509_VERIFY_PARAM_set_flags() to disable the openssl/libressl rfc3779 checking following the original algorithm and as a \"temporarily\" measure a callback to catch the 3779 verification error; but yeah, there is work to be done in both openssl and libressl, and we are willing to take on that work

", "time": "2024-03-19T06:45:30Z"}, {"author": "Rob Austein", "text": "

@job that's plausible. we can thumb wrestle over details but i think the basic approach is ok.

", "time": "2024-03-19T06:46:15Z"}, {"author": "Job Snijders", "text": "

the goal is to make it easier for future implementers (through libraries), provide guidance for current implementers (demonstrate how to do callback), and I know its a lot of work in a delicate area of the ecosystem, but luckily there are a number of libcrypto people willing to help and review

", "time": "2024-03-19T06:47:22Z"}, {"author": "Rob Austein", "text": "

cool

", "time": "2024-03-19T06:48:17Z"}, {"author": "Job Snijders", "text": "

Overview as I understand it:

\n

rpki-client + FORT - depend on C libcrypto, will need to take on complications to make things work
\nRoutinator: has its own Rust rpki-specific validator/chain builder, for them this change might be a 3 line diff
\nrpki-prover: a Haskell project, I'm not 100% sure where it gets the chain validation bits from, or was bespoke original implementation
\nRPSTIR2: AFAIK uses Go bindings into openssl

", "time": "2024-03-19T06:53:14Z"}, {"author": "Ties de Kock", "text": "

rpki-validator 3: already has a feature flag for this :speak_no_evil:

", "time": "2024-03-19T06:53:40Z"}, {"author": "Rob Austein", "text": "

my ancient code (which i assume nobody is really using for validation these days) also used libcrypto.

", "time": "2024-03-19T06:54:28Z"}, {"author": "Ties de Kock", "text": "

there is a few (< 5) rcynic instances out there, some without RRDP enabled

", "time": "2024-03-19T06:55:11Z"}, {"author": "Job Snijders", "text": "

AFRINIC uses rcynic for inspection and compliance testing: https://validator.afrinic.net/rpki/rcynic/rpki.afrinic.net.html

", "time": "2024-03-19T06:55:32Z"}, {"author": "Keyur Patel", "text": "

thank you and see you at ietf120 :)

", "time": "2024-03-19T07:00:40Z"}, {"author": "Keyur Patel", "text": "

and at the interims

", "time": "2024-03-19T07:00:50Z"}]