Minutes IETF115: sidrops: Thu 13:00
minutes-115-sidrops-202211101300-00
Meeting Minutes | SIDR Operations (sidrops) WG | |
---|---|---|
Date and time | 2022-11-10 13:00 | |
Title | Minutes IETF115: sidrops: Thu 13:00 | |
State | Active | |
Other versions | markdown | |
Last updated | 2022-11-28 |
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