SIDROPS 115 Session: Thursday 10 November 2022, 13:00 - 15:00 UTC Session recording: https://www.youtube.com/watch?v=lHV8OaY5cj0 Session materials: https://datatracker.ietf.org/meeting/115/session/sidrops 1) Agenda bashing and Chair's slides - \[5 minutes\] There were no comments or questions 2) Challenges and Lessons Learned in deploying RFC6492, 8181 and 8183" Tim Bruijnzeels - 20 minutes**\*\*** There were no comments or questions. 3) An update on Source Address Validation Using BGP Updates, ASPA, and ROA" (BAR-SAV) https://datatracker.ietf.org/doc/html/draft-sriram-sidrops-bar-sav-01 Igor Lubashev - 15 minutes\*\* Jared Mauch: Some feedback on slides 9 and 10. We have some internal cases where this will not work. Just on the networking side we have internal interconnect customers that might get incidental transit from us out to the public internet if we have a cluster that disconnects from our global backbone based on how the aggregate IP space is announced. It's possible in this case that we direct a customer to a location that is off-net because we have taken it off-line for maintenance. So the source address may be the customers IP address that we are not really intending to provide transit to but we also don't want to break. Because if there is an external system directing them to talk to a specific server, hypothetically speaking, that system might not know what is real-time connected to the backbone in the routing information. This will make it challenging for us to talk to our network providers and ask them to implement this on our ports. Igor: Let's talk offline. If we're purely talking about reluctance to publish ROA data for SAV purposes.. Jared Mauch: It may be that we have a customer that is a dark origin, that they don't want us to announce their IP space. We can talk offline. On slide 10, the concept of using things that are still valid, so ignoring the experation. There is precedence in DNS. In the "use stale", so that makes sense. Antoin Verschuren: When we are implementing customer cones based on BCP84, there is a warning for customers that have a large customer cone in number of prefixes (over 5000), our own customer cone is 1,3 million prefixes. How is BAR-SAV going to change calculating prefix filters? Igor: I'm assuming that you have a lot of customers. All the SAV techniques work best closer to the edge. I'm not sure how a tier-1 network would do that. Antoin Verschuren: Is this approach different than generating it from IRR data? Igor: It does not matter where you calculate it from, it does not have to be computed on the router, it can be done on a server next to the router using the feeds. Antion Verschuren: So if we can't do BCP48 now, BAR-SAV won't change that? Igor: This effort is to try to come up with a more accurate SAV list. Nan Geng: During the evolution of SAV, we have included more and more information over time, using different mechanisms. Keep in mind the extra costs. Igor: Yes, there is a computational cost, but with regards to the RPKI data, people will update that anyway. Job Snijders: Section 6.5.1. suggests refreshing daily, while existing work recommends at least once an hour, preferably once every ten minutes. I don't see a justification to deviate from what is already an established best practice. Igor: This is good feedback. Daily is an initial placeholder. Job: I struggle with ignoring experation dates. I would not implement that in my validator, I see no justification for doing so. The document already describes a fail-open mode where it is suggested to fall back to enhanced uRPF because that downgrade is better than suspending SAV entirely. I think it's good to consider a path towards a fail-open of sorts but ignoring objects being delisted from a manifest, which would cause them to not appear on a CRL, but it means the CA revoked the ROA, or ignoring the expiration date is unhelpful. Igor: The recommendations were not for processing the traditional RPKI ROV, but only for SAV purposes. The concern is that if you start pretending objects don't exist, for example if you fail to refresh your cache, and the object is expired in the meantime, falling back to enhanced RPF means that some of the data that was available from RPKI will no longer be available and your SAV list will become smaller. This is something you don't want. Job Snijders: What is the garbage collection mechanism? I do understand your concern that it is operationally nicer to be more permissive than strictly needed, but somewhere in the decision path you need to make a decision. For instance if I see a traffic stream coming from you towards me and I own the IP space and I want to block it, and I remove the ROA authorising you to send traffic to the source, and others continue to use that ROA that now has been removed from the system, pretending it didn't expire, or wasn't removed.. Igor: Put it in a CRL.. Job Snijders: But then you are changing some fundamental parts of how RPKI was designed to work. The CRLs shrink based on what properly expired but also if it's not listed on a manifest you don't need to add it to a CRL. CRLs in RPKI are fairly small, this is possible because Manifests are strictly interpreted. Igor: We can look at the guarantees of consistency you can expect from the repository. If we believe the repository has a good consistency, and it does not accidentally drop objects, then we don't need this recommendation. Job Snijders: Manifests were meant to provide very strong guarantees about the integrity of the repository Mingquing Huang: If we are augmenting a table from RPKI data and RPKI fails, we put that prefix at risk, correct? Igor: That's why we have this implementation guidelines, though some of them are clear, some we need more discussion on. We need to be very careful managing our cache so that any failure doesn't result in "failing closed" for any prefix. Doug Montgomery: With regards to RPKI staleness I think we have to follow the basic RPKI validation algorythm is doing, and what Route Origin Validation is doing. If we change the behaviour around staleness we might need a new object, which we agreed to stay away from. Igor: We will take the call for WG adoption to the list 4) Signed TAL https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-signed-tal-12 Tom Harrison - 10 minutes Russ Housley: You are right about my suggestion being small, but I looked for the document that is updating that registry because the previous one was already in AUTH-48, and Warren said "I won't add it." It seems a small thing to do a whole RFC for. Warren Kumari: Russ said part of what I was going to say. On the previous slide (6): What I was wondering, if the TA compromise section could be put in an appendix? In stead of removing. That way, it's just "here is some additional information". Ties de Kock: Let me clarify my main concern over the key destruction. The limitations that I've seen with the various vendors that we've looked at for HSMs, is that you cannot be certain that there is no copy of a key somewhere. This is why I was opposed to it. 5) pdate on ASPA-Verification https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-11 K. Sriram - 15 minutes Job Snijders: It is OpenBSD's intention to implement ASPA verification in 3-6 months, which is fairly soon. Maybe wait a bit for working group last call, until we have finished the implementation. I also hope some other vendors will start working on this soon. Sriram: At NIST we already have already implemented close to this latest version 11. This is all on GitHub and we welcome anyone interested to make use of the tests and implementation. In addition to that, Claudio Jeker in his comments on version 11 on the list mentioned that he is implementing it. It's good to see multiple implementation efforts on the way. Tim Bruijnzeels: On the CA side, NLNetLabs did an implementation based on the syntax that was in one of the documents but we need clarity on if this will be the actual syntax. This is what is stopping us on the validation side. Experience in implementing something that wasn't solid and having to revert it wasn't very nice. If we can have clarity on that, we can do more work on the validation side. Job Snijders: In terms of the profile, in my perspective it's now stable. There are multiple implementations. Specifically your CA implementation helped me develop RPKI-clients implementation. The current profile draft contains references to seven or eight implementations that -to some degree- have tested operability. So far as I'm concerned, unless there is a grave mistake in the profile that needs addressing, we should stop touching the profile. From a CA perspective, I'm ready to publish ASPA profiles conform the latest profile in the public RPKI. I will do so in the next few months. Ties de Kock: RIPE NCC has an implementation of the current draft of the ASPA profile in the CA environment available on a testbed and we will publish the documentation on how to create objects soon. However, one validator implementation will complain about unknown objects. Keyur: IDR should be reviewing this work. Chris and I will follow up with you. 6)Update on the RC6482bis effort https://www.ietf.org/archive/id/draft-ietf-sidrops-rfc6482bis-01.html Job Snijders - 15 minutes Jeff Haas:The main reason, historically, that constraints were not set on ASN.1, is the toolset. While I agree that additional constraints might be handy, your real question is whether or not your implementation will slow down because the increased difficulty to get the job done. Job: The constraints as used (back to ASN.1 slide), the only two constraint types that are used here are a size limitation and a value range limitation and those are supported by all the ASN.1 compilers I'm aware of. The original ROA specification is a bit over twelve years old, so times changed to some degree. Russ Housley: I see no harm putting it here where they get a decoder or a checking for consistency error. Either way, you have to perform the same checks. Warren Kumari: Go back to slide 3. That was indeed a judgement call, on rejecting that. Job: Arbitrary judgement call. Warren Kumari: I think allowing a comment is less of a big change than this. But I'm glad I rejected it because this looks like a much better outcome. Job: I agree that taking this opportunity to do a -bis document is a better outcome. Jared Mauch: About slide 10, I agree we're not going to have negative ASNs, looking at the future could we have ASNs that exceed this range in the future. That is my concern, if for some reason we need to change all the ASNs, move them to 64 bit, I have reason to believe that we'll still be using the same BGP4 protocol..I have a hard time thinking that we should constraint ourselves to 32 bit. Job: If ASN numbers are specified to 64 bits, or 128, the path to extend this profile is fairly straight-forward. On line two there is a version. If the symantics of the data structure elements were changed, you would use a new version number Jared Mauch: Are you saying we do the version number in your proposed change? Job: These changes all reflect version 0, as deployed in the wild. It's all constraint in the current versions of RP software. It's just not in the spec. If the ASN values change, we need to change more specs. George Michaelson: I think there is benefit in being restrictive. It helps against bad actors. George: Michaelson: A personal comment directed to the chairs and ADs: The errata and -bis process in the IETF is insufficiently understood and documented. And irrespective of the merits of this proposal, I believe risks of contention and dispute around how -bis happen actually is a problem that should be addressed. It is a WG chair matter and an AD matter. It's not a matter of authors. Job: To reitterate, my goal is to clean up loose ends and then ask for WG last call. Should you want to contribute to that effert, please help review the document. * Finish