Session Date/Time: 19 Mar 2026 03:30
Speaker 1: Hello Joe, can you hear me?
Joe: Yes.
Speaker 1: Yeah, I think Lancheng has to update slides waiting for approval.
Joe: I've approved everything that came through.
Speaker 1: I guess they- he sent two new updates this morning. I didn't see since general- if it's already approved.
Joe: Of all the ones I've gotten today, I've approved. Let me double-check. Of all the ones I've gotten today, I've approved. And I don't have any queued, so I hope we have the right slides. I just- we'll have to deal with it. I was trying to keep up, but last-minute updates can be a problem. Okay, thank you everybody for attending this session. This is the SAVNET Working Group. Ron and I are the co-chairs, Hau-yu is our Working Group Secretary and sitting at the front of the room to help us monitor the room since both Ron and I are remote for this session. This is the Note Well. While you've seen it before, it is important for every session. Please follow it. It describes- gives you links to all of the detailed procedures, describes the general rules for contribution and for behavior. I'm not going to paraphrase it because that would introduce error. So please, if you haven't read it recently, read it. Thank you. We're short on time, so I'm gonna try to go quickly through this. It's a reminder, please make sure you sign into sessions and use the Meetecho tool. You can use the light version or the in-person setting so that you can put yourself on the queue, because we will be explicitly using queue management via Meetecho, even if you're in the room. If you're a remote participant, please make sure your audio and video are off unless you're presenting. Ron and I will probably both be muted most of the time when presenters are going so that we don't accidentally get in the way. Also, to everybody, in addition to the Meetecho identification, please state your name to the microphone when you come up. That will help everybody know who is speaking. Thank you. These are links that you probably have already seen: the overall agenda, meeting preparation information, and how to report issues. This is the first half of the agenda. As soon as I finish, Libin Liu will begin with the update on the inter-domain, then Lancheng will talk about authoritative information and TOAs, and well, you can see- and then we'll move on to Sriram, and then an update again from Lancheng on the intra-domain. And if time permits—and we don't know if it will because we only have one hour—we'll talk about- we'll have a presentation from the folks working on monitoring source address validation deployment. Are there any questions about the agenda? If not, as per this, I will pull up the inter-domain gap analysis and I will hand control to the slide clicker. So Lancheng, you should have control of the slides via the clicker.
Lancheng: Oh, this is intra-domain. I will present inter-domain.
Joe: Oh, this is intra. Did I get the wrong one? Sorry. Let's get it right. You're right, that was the intra-domain. I hope this is the right one. Yes, there's the right one.
Lancheng: Yes, thank you, Joe.
Joe: Thank you and sorry for the mistake.
Libin Liu: Okay, I'll start. Hello everyone, I'm Libin Liu from Zhongguancun Laboratory. Today, I will introduce the updates on the inter-domain problem statement draft, specifically draft-ietf-savnet-inter-domain-problem-statement, and mainly the major revisions made in version 15. This presentation mainly focused on three things: where the draft is now, what kinds of comments we received during the working group last call, and how these comments were addressed in the updated text. Let me first briefly introduce where the draft is now. The document is mainly about gap analysis of existing inter-domain source address validation mechanisms, the problem statement, and the requirements for future improvements. At this point, the draft has reached the working group last call. All the feedback we received are positive and helpful. Most of them mainly target the clarity, terminology, and requirement awarding. Thank you very much for the feedback. Compared to version 14, in version 15, the core direction of the document remains unchanged. And in version 15, we mainly resolved the main ambiguities raised in the discussion. I think this will make the document more clearer and stable to move forward. Looking across all the comments, the feedback falls into five categories. The first one is requirement language. Some members commented that in the earlier wording about the use of "must" were too strong, and especially for the general technical improvements. The second type is scope boundaries. Some members commented that the document should explicitly state the inter-domain SAV should refer to the SAV on AS-to-AS interfaces that carry the EBGP sessions. And also, we received one comment that says the document should state earlier in the introduction and explicitly states that packet modifying approaches are out of scope of this document. The third type is about the provider-side spoofing. The comments suggested we should revise the name of the scenario and states that the improper permit from provider interfaces is important. The fourth type of comments is about the terminologies. Some members commented that we should revise the definitions of SAV-related information and SAV-specific information because currently they are more RPKI-centric, which may lead to a bias towards a- an RPKI-based solution. The final is about- is something about editorial clarity. For example, the reference abbreviations and the figures about the DSR scenario. So, all of the comments aim to make the draft more precise, less ambiguous, and easier to use as a basis for the future solutions. Here is a high-level summary of the revisions in version 15. The first one is normative language. In the updated version, we have revised the requirements from absolute improvement claims to a clearer baseline. For example, the concrete modification is that any new mechanisms must not be worse than existing ones and should improve the filtering behavior. And for the scope and modification, in the updated version, the document explicitly stated that the inter-domain SAV refers to SAV on AS-to-AS interfaces that carry EBGP sessions. And also in the introduction, we also stated the- scope limitation about no packet modification on the data plane. About the provider-side spoofing, we have revised the name of the scenario and with clearer explanation about what the provider may originate or relay the spoofed traffic from its customers or peers' customer cones. About the terminology, we have revised the SAV-related information and SAV-specific information. We also did a number of the editorial changes, added the informative references, revised the figures about DSR scenarios, and removed some abbreviations to improve the readability. The first major issue is about the use of "should" and "must". Several members commented that original "must" language in the requirements were too strong. For example, avoiding improper blocking in an absolute sense, which is unrealistic under partial deployment and practical routing scenarios. Also, some members suggested to compare new mechanisms with current ones rather than require universal improvements in every metric and every scenario. So in version 15, first we kept a firm baseline. The concrete statements are: any new mechanism must not be worse than existing inter-domain SAV methods in terms of improper block and improper permit, and any new mechanism must have less operational overhead than ACL-based ingress SAV filtering. And second, we also moved the improvement claims to- general improvement claims to "should". Any new mechanism should avoid improper blocking and improve the directionality of filtering, that is, reducing the improper permit. And any new mechanism should be able to automatically adapt to the network dynamics and asymmetric routing scenarios. So, I think these requirements remain strong, but they can be more realistic under the operational scenarios. The second issue is about the scope clarification. We received one suggestion which suggests us that the scope limitation in Section 7 should also appear much earlier in the introduction. So in the updated version 15, the introduction now states that new inter-domain SAV mechanisms should avoid packet modification in the data plane, which is consistent with the descriptions in the charter. And also, the introduction also states that the packet-modifying approaches are outside the scope of this document. So, I think this revision makes the design space explicit. The document studies validation and filtering mechanisms without modifying the packets on the data plane, and that keeps the problem statement aligned with the intended solution space and avoids mixing in additional interoperability and deployment questions. Another major issue is that about the provider-side spoofing. Amir suggested us that the draft should state more explicitly that reducing improper permit is important at provider interfaces. As replied on the mailing list, that the document does have the requirement for reducing on improper permit at the provider interfaces. Also, we received the comments that the wording about SPT may not be fully clear. The spoofed traffic may come from the provider directly or be relayed from its customer- customers. So in the updated text, we have revised the name of the scenario to "spoofing from providers" and also the text says that a provider may generate spoofed traffic itself or may relay it from its customers or peers' customer cones. We also received comments about the definitions of SAV-related and specific information. Some comments noticed that the SAV-related information seemed in the earlier wording seemed to RPKI-centric. Authors also pointed out that the routing information such as RIB and FIB should belong to the SAV-related information. Also for the SAV-specific information, the wording should also allow not only a new inter-AS protocol, but also an extension of an existing protocol. We updated them all in the version 15. SAV-related information now explicitly includes the routing information such as RIB and FIB, as well as RPKI objects that may be used for SAV. Also, SAV-specific information is described as the information dedicated for SAV, but that may be exchanged using a new proposed protocol or an extension of an existing protocol. So, I think this makes the terminology more implementation-neutral and better aligned with the discussions in the SAVNET Working Group. And we also have a number of editorial changes, which help reduce the misunderstandings. For example, we added the RFC 8704 as informative reference, and we also refined the wording such as selective AS-path policies for traffic engineering-related cases as suggested by Jeff. And we also revised the example figures on the DSR scenarios and the corresponding description text about the figure as suggested by Igor. And we also normalized the terms such as P2P and route server. We also reduced the use of many abbreviations like HOO, RPP, and HPP in the contents and to improve the readability of the draft. We also clarified the AS's client-related interface in the- in the document. So what version 15 achieves here: it provides a clearer problem statement. The document now states the scope, the provider-side spoofing problem, and the intent of requirements more directly. And it gives a more stable requirement set. I think the requirements here remain strong, but they are more realistic under the operational environments. And it provides better basis for the next step work. I think the- the draft is better positioned to support future solution design and evaluation in the working group. So, the working group last call feedback helped sharpen the document. Thank you very much all. So, the conclusion: the draft has now addressed the main concerns raised in the working group last call, and the discussion has been constructive and convergent. The working group members helped us remove misunderstandings. So I think at this point, the document is in a stronger position to continue progressing. Okay, many thanks all for the reviews, comments, and suggestions. And thank you, questions or comments are welcome.
Joe: Go ahead, Nan.
Nan Geng: Well, Nan Geng from Huawei. Thank you, thanks for the update of the draft, and I think my comments in the mailing list have been incorporated in the new draft well. And two more comments. First, since we have updated the terminology section and some terms such as SAV-related information and SAV-specific information have been updated, so the terminologies in the architecture drafts should and will be updated in the future- in the next version of the drafts. So people who are confused on the terminology definitions can pay- pay attention to the updated architecture drafts in the next submission version. And second, another comment is that in the existing inter-domain SAV mechanisms, SAV-specific information is not defined or used. So this term is introduced in the intra and inter problem statement drafts and in the security considerations section, I think the analysis of the maybe risks imported by the SAV-specific information should be analyzed further. Maybe you can add some more descriptions on the potential risks of the SAV-specific information as described- the draft proposed by Lancheng. Thank you.
Libin Liu: Thank you. Yes, we will discuss the terminologies. I admit that keep the terminology consistent across different documents is important. In the current version, we have- we do have some security considerations in the document, but we will check it. Yeah.
Lancheng: Lancheng from Zhongguancun Lab. Just a brief clarification that the intra-domain problem statement also received some similar comments including on the comments on the use of "must" in the requirements, but we didn't simply apply the same fix. We considered the differences between intra and inter-domain SAV, so we revised the intra-domain problem statement accordingly, and I will introduce our updates later. Thanks.
Joe: Thank you. Are there any other questions? One more, we just have a little bit of time. Go ahead, Rudiger.
Rudiger: Just simple question: is the opinion that this is actually kind of closing the working group last call or is another one called- another call requested for version 15?
Joe: The chairs will have to discuss that. I think things converged enough that we're probably going to accept it as is, but we need to review the list and decide whether there is a need for another call. We haven't done that yet.
Rudiger: Ah well, okay. Another round of review might be a good idea.
Joe: We will take that under consideration. Thank you for the feedback. It's certainly more important that we get this right than it is that we get it out the door in a specific date. So we'll consider that. Okay, Lancheng, you're up next. I'm starting the timer for 15 minutes, but that's for both of your presentations.
Lancheng: Thanks, thanks Joe. I'm Lancheng from Zhongguancun Lab, and TOA is a new type of source authoritative information, and it has been discussed a lot on recent SAVNET and SIDROPS mailing lists. And today, I will provide a quick overview of TOA and summarize the recent discussions and outline our next step. First of all, I'd like to share two important terminologies: they are root origin and traffic origin. The root origin of a prefix is the AS authorized to originate routes to the prefix in BGP. And the traffic origin of a prefix refers to the AS that is authorized to originate data packets using source addresses in the given prefix. And generally, we might think the set of traffic origins may include root origins, and it may also include additional ASes that only originate data packets but not originate routes. And here comes a divergence between traffic origin and root origin, and this is a key challenge in SAV. Because current SAV mechanisms will validate source addresses. The procedure is mostly built on the root origin authorization, and they may use BGP updates or RPKI ROA, which actually represents destination information to identify the source information. But in most cases, this works well when the traffic origin is also a root origin. But in some cases where the traffic origin is not a root origin, improper block happens. And this scenario usually happens when the route to the prefix is not authorized to be announced by any AS, for example, in the unidirectional traffic scenario. Or the root- the route to the prefix is authorized to be announced by ASB, but the actual root origin is ASA—they are two different ASes. So to improve SAV in these scenarios, we think we need an explicit mechanism for source address authorization. So, we propose the concept of TOA: Traffic Origin Authorization. It is a SAV-specific RPKI-signed object, which explicitly authorizes an AS to originate data packets using source addresses in a given IP address block. And it is particularly useful in scenarios where the traffic origin is not a root origin. And it's also useful when the traffic origin is the root origin. But as discussed on the mailing list, to avoid TOAs simply duplicate existing ROAs, we recommend that operators should not register TOA that is identical to or covered by an existing ROA. And we can see TOAs have pretty applications because it can be easily used by several ongoing SAV proposals including BAR-SAV. And a TOA can contain a set of AS numbers and a set of IP prefixes. The semantic of a TOA is that every AS in the AS number set is authorized to source traffic from every prefix in the prefix set. After last Montreal IETF, we have discussed how to handle overlapping prefixes in TOA on the mailing list. For example, there are two TOAs: the first TOA contains AS1 and a /24 prefix, and the second TOA contains AS2, another AS, but with a more specific /28 prefix. And the working group consensus is that both ASes- both ASes are considered authorized for the more specific prefix when originating data packets. And if the goal is to restrict AS1 from the more specific prefix, the first TOA must be modified. And recently, Sriram raised an issue that the draft mentions nothing about the need for an AS0 ROA. But we think this document should only include TOA-specific operations and considerations, but ROA-related consideration for root hijacking provision is out of the scope of this document. So in the next step, we'd like to coordinate with SIDROPS Working Group and seek feedback on the eContent format. Actually, we already sent an email but received no response. So we have a question to our chairs: we think maybe before going to SIDROPS, the draft should first be adopted. So- thanks. Any comments to this presentation? Rudiger, are you still on the queue or is that again?
Rudiger: That's again.
Joe: Go ahead.
Rudiger: Yes, I wonder if there is some network emitting routes- no, packets, packets for something where you are- well okay, where there is no traffic- well okay, kind of- are there cases, are there cases possible in the real network where there is no AS seen anywhere in the network for someone legitimately emitting packets with source addresses for well okay, whatever they are.
Joe: Rudiger, the- the drafts discuss the various hidden prefix cases and whether they're prefixes which show up elsewhere or prefixes which show up nowhere. And so that- that is discussed in the draft. I don't want them to take the time here because we're running a little short of time.
Rudiger: Okay, thanks. Sorry.
Joe: It's okay. Michael, you can go. I would want to remind people, we'll come back to the specific questions of TOA-ROA interaction after Sriram's presentation in a- in a little while, so we don't need to discuss that one yet, although we will definitely need to get to it. Go ahead, Michael.
Michael: Hi, this is Michael from Zhongguancun Lab. Basically, I support the idea that new type of object TOA to, you know, do something for our source address validation. The thing is that we want to make the RPKI- the routing security origin validation clean and neat from the system design point of view. I don't want, you know, get some new data, RPKI data or, you know, new type of thing that I don't recognize. I have to update my system to- it to adapt to this new kind of thing when we do ROV. This is basic idea. But another thing is that I want to comment that we may need to do more, you know, scenarios case in the situation what kind of a case that the traffic origin is kind of different with routing origin. Indeed, Lancheng shared some case, but we may need to put that more, you know, clear and- and doing more analysis what kind of scenarios may raise this kind of thing.
Lancheng: Yeah, yes. Jeff, Igor have already shared some cases and- but more cases are welcome. Yes, thanks.
Joe: Okay. And now go to the next presentation.
Lancheng: Yeah, thank you. Yeah, this is a new draft, specifically draft-ietf-savnet-general-sav-capabilities, provides some considerations on authoritative information for source address validation. And we- I think we all agree that SAV should rely on authoritative information to determine which source addresses are legitimate. And however, some problems may arise when using such information. This document provides a conceptual framework for understanding authoritative information in the context of SAVNET, including the following four questions. The first question: what constitutes authoritative information? We believe authoritative information should meet the following criteria, including organizational authority, verifiability, timeliness, integrity, and security. And by following those criteria, typical authoritative sources for SAV may include RPKI objects and local configurations. But there is a note that even if the information is from an authoritative information, it may occasionally be incorrect or stale. But sadly, we think it's difficult or even impossible for SAV to verify the correctness of authoritative information because we have to trust them. The second question is how to handle missing authoritative information, especially in the incremental deployment scenario. The problem is that SAV may lack authoritative information for some prefixes or source entities because there is no relevant RPKI objects or the local operator configuration is not defined. And we list some possible approaches to handle traffic in this scenario. For example, somebody may choose to block traffic in this scenario by default. This approach is safe but may drop legitimate packets. Another way is to allow such traffic by default. This can avoid improper block but may accept spoofing traffic. So, we believe the most practical way is to further use non-authoritative information to fill this gap. This can enable incremental deployment, and the SAV enforcement is just to take intermediate actions. In addition to- just permit or block, they can take actions such as rate limit, redirect, and monitor monitoring. And there is also a note when using non-authoritative information to fill this gap because non-authoritative information may be incorrect or stale and they should be validated before using for SAV enforcement. How to reconcile conflicting authoritative sources? This problem is that when multiple authoritative sources may provide conflicting statements. And in this case, we suggest that we should treat all sources as equally credible. But although non-authoritative information may be used as a reference to support further understanding, they cannot override authoritative information. And as we can see, this draft is in a primary stage and some future work is needed. And so in the future, we plan to refine the authoritative attributes and sources, detail principles when using authoritative or non-authoritative information, and explore how SAV authoritative information can be registered or maintained at the sources as well as how to be coordinated across different authoritative sources. And we also welcome comments and collaborations to improve this draft. Thank you.
Joe: Any questions for Lancheng on this- on this authoritative information topic? Yes, if- if have any suggestions, comments are welcome also on the mailing list. Thank you. Go ahead, Rudiger, you- you have a comment.
Rudiger: Yes, actually, well okay, I think you have to- explain and divide discussion along the- the time horizons, how data actually changes. Looking at your timeliness thing, asking that authoritative data should be- should be in line with operational status, that's just impossible. Operational status changes all the time, and- and kind of most of the operational status, well okay, we don't know whether we can take that as authoritative, but it is the operational status. And on the other timeline, say RPKI, people are dealing with strategies that they code into databases and that may- that may mean I put in a- a ROA for eventual use to authorize something to patch an emergency in advance, and well okay, that's going to be authoritative. But it will not be in the operational status for most of the time, if ever.
Lancheng: Yeah, I- I think your observation is basically correct, and I agree that the timeliness is a fact instead of a feature of- of sources. And I- I can- we can discuss it deeply and I will make this clear in the document.
Joe: Okay, thank you very much. Sriram, you're up, and I'm handing you slide control.
Sriram: Thank you, Joel. You can hear me all right?
Joe: Yes, we can hear you.
Sriram: Okay. Yep. So this work relates to the TOA presentation earlier. I looked at two possibilities to handle those prefixes which- which we can say are not routed but used for source addresses. Those two possibilities are ROA-only or ROA plus TOA method. And I thank a few people, Igor and Doug Montgomery, for discussions that helped the- the preparation of this presentation a lot. I'll be skipping a few slides because I have quite a few slides, and some of the discussion items got clarified in the extensive discussions that took place already on the SAVNET and SIDROPS working group list. So let's start with the three types of prefixes that that we are looking at. Type 1 are allocated to a specific AS or- or they are associated with a specific AS. They are used for sourcing externally but not advertised. I put some ballpark estimates for these. All these prefixes together in SAVNET we have been calling it a very few prefixes, and I put like a very generous maximum limit on these in the right-hand column. Type 2 are IANA special-purpose prefixes that are source equals true and destination equals false, which means they can be used for source address but not destination address. And these- these are not associated with any specific AS. They may originate anywhere from any AS. These are like IP ICMP error messages and such are included here. The third type are CDN DSR, which- which we have been discussing in the working group for some time. Together, these three types of prefixes constitute only 0.01 percent to 0.06 percent on the very high side. So we are talking about a small number of prefixes. I will skip a few slides to go to slide 6- no, 7 rather, because the the- the other slides, the semantics of ROA TOA got discussed fairly well, I think most of us are in sync with that. So in the most recent emails exchanged on the SIDROPS SAVNET post between Jeff and myself on this topic, the ROA can be- I mean, the ROA explicitly authorizes origination of the route, and it can be thought to be- I mean, it is a design choice, that's how Jeff would like to call it. I was calling it an implicit authorization by the- by the ROA, but it's a choice of words. So Jeff would call it a design choice rather than an inherent property, but we can use the ROA for AS- that the AS may source traffic from that prefix. TOA authorizes the right-hand part of it. It AS may source traffic from the prefix, and TOA doesn't say anything about the routing part of it. So the two methods that we will look at, we need to have like why- what the methods are for. So there is a functionality requirement for these prefixes, that is, the method that we- that we design to discover these prefixes for SAV purpose, for SAV purposes, the method must discover the prefixes for SAV inclusion. And there are general SIDROPS IDR goals for prefix security or route- route security that are based on ROA and ASPA, OTC, so they are applicable to all prefixes anyway, and they are applicable to those- these special prefixes as well. So we are comparing these two methods: ROA-only method, in which the the- prefix registers a ROA- prefix owner, or if the AS owner also owns the prefix, a ROA is registered for the prefix with the AS, and the- the prefix is not announced in BGP from that AS. And for the TOA plus ROA method, a TOA is registered, authorizing the source address part, and a- an AS0 ROA must be registered so that if the prefix is not routable at all, anywhere, then AS0 ROA takes care of it. And then again, do not announce the prefix. So, those are clear. So the- between these two methods which we call ROA-only vs. ROA plus TOA method, they both meet the- the requirement in terms of being able to detect the- the prefix in order to be able to discover the prefix for SAV, they are both equivalent in that function, except that when you consider dynamic traffic engineering cases, which are on slide 16 and 17—we won't be able to go through that today, but in- in those cases, the TOA plus ROA method has disadvantages. So, comparing these two, so they both are capable of protecting against route- route hijacks because the ROA is there. And in terms of the- the special prefix case where the prefix is routed but not originated from the same AS, the TOA plus ROA method is- is useful for forged origin prefix hijacks, but that's a slim advantage because we do have ASPA, which- which provides that protection for all prefixes in the internet. So we can- so that's for- am I there? Yeah. So we'll- we'll skip this slide, which has to do with type 3 and type 4. These methods can be used for type 3 type 4 also, and here the ROA method has distinct advantages. It doesn't have any disadvantage compared to the ROA plus TOA method. And for type 2 also, there's a clean solution of- not why- what I described here, but in the ROA- in the BAR-SAV draft, there's a clean solution that allows the handling of type 2 in an automated fashion. So my final slide: the key tradeoffs are both methods discover the prefixes, the traffic engineering flipping of multi-origin prefixes, ROA method provides stability and operational simplicity, so in this case, the TOA plus ROA method should not be used, it would be detrimental. Again, like we have to- for the TOA plus ROA method, we have to go through SIDROPS for the new RPKI object, which involves time and effort, and we need to take- we need to see what the advantage of that in terms of the performance it provides: a slight marginal advantage for- for guarding against forged- forged origin prefix hijacks for these special prefixes, but then we have the ASPA solution. And then finally, the TOA plus ROA method can result in unnecessary TOA proliferation. People may not understand that TOA is not necessary when ROA is there, so that- that confusion can cause unnecessary proliferation. So there are many slides, I would like to request you to go through them, they- they provide further deeper analysis. Thank you.
Joe: Questions, either for Sriram specifically or about the general topic of TOA versus ROA or versus TOA plus ROA. Go ahead, Lancheng.
Lancheng: Lancheng from Zhongguancun Lab. Hi Sriram. Actually, I have a couple of comments and a couple of disagreements regarding your presentation, and I already shared some of them on the mailing list. Due to time limits, now I will focus on what I think is- is the most important issue. Could you turn to the page 5- the page 5, please? Yeah, yeah. So in your slides, the semantic of ROA and TOA are incorrect because-
Sriram: Page 5 you mean page 6? Page 5 is old. That was the old definition of ROA. The new definition of TOA is on slide 6. You may continue if that is good.
Lancheng: Yeah, because the correct ROA semantic is simply authorize an AS to originate routes. and the semantic of TOA is simply to authorize an AS to originate data packets. They are different, so I don't believe, I don't agree that you said ROA semantic includes TOA semantic. That is- so, based on the wrong semantics in your slides, your subsequent analysis and examples are all based on the incorrect semantics from my view. So I would suggest that it's very important that you should keep the semantics very clean so that we can discuss your analysis and we can further reason about the design space. Thanks.
Sriram: We are short of time, but let me quickly answer that question. As I said while describing this slide, that if you look at the latest few posts between myself and Jeff, the ROA can be used for source address inclusion also, and that is a design choice as Jeff would call it. So effectively, ROA allows you to use it for source address inclusion in the SAV. So in that respect-
Joe: Let's keep the questions quick, but I want to give everybody time to discuss because this kind of discussion is what the working group is for. So, go ahead, Jeff.
Jeff: Thanks Joel, I'll keep this brief. So this is mostly for the minutes, this is in the chat and also the mailing list. AS0 ROAs say this route is always invalid. This is very distinct from saying, "No, this is a ROA for this AS with the idea that it will be not announced and will be trapped by RPKI-now-filtering routers." These are not the same things. RPKI at the moment is only able to constrain no intentional hijacks. This is the core difference of the properties. Thanks.
Sriram: Jeff, is that about the semantic or is that about the creation of the AS0 ROA versus a normal ROA for the- for the prefix?
Jeff: So if the filters do not include AS0 ROAs, that means there's no way to actually say, "I want to announce this, no, I want to source traffic from this destination, and I do not want this seen in EBGP." To do that you need the separate piece of state, which is what the TOA would cover. I'm not insisting the TOA's the right answer, but something in that shape is the necessary piece that fills the gap. Thanks.
Sriram: Right, that is where the little tradeoff comes in, that if you do so define a separate RPKI object like the TOA, it provides the additional protection for- for these few prefixes from forged origin hijacks. But if you create a normal ROA as we are proposing for the ROA-only method, then the- that protection from forged origin hijacks is not available. But- but that is compensated somewhat by the ASPA protection of the AS-path.
Jeff: I agree, RPKI only helps constrain the hijacks at the moment. Anyway, we've articulated the necessary property, that's what I'm looking for. Thanks.
Joe: Michael.
Michael: This is Michael from Zhongguancun Laboratory. Again, I just like mentioned earlier that I- I like the idea that want to make route origin verification clean and clean. And this is from a system design point of view. Another thing is about if we reuse the AS0 ROA but as kind of thing that one prefix may originate route, but also for take this CDN for the case also the- they want to, you know, send the source traffic from another AS. For me, this kind of thing that we if we want use ROA to do this kind of purpose, I- I don't get how can we do that. Okay.
Sriram: So I think that extends Jeff's question to- I mean, if you have like the DSR CDN scenario, then in that case, the prefix is routed from another AS, but from one particular AS, the edge AS, the prefix must not be routed, only it is used for source address. For those cases, there is no option of creating an AS0 ROA. You would only create the normal ROAs as we are proposing for the ROA-only method, with the ASes that do originate it, the anycast ASes. But the edge AS would- would also create a ROA. Sorry, yeah, but not- the edge AS would create a ROA but not originate the prefix. And that overall would protect the- sorry, yeah, but not- the edge AS would create a ROA but not originate the prefix, and that overall would create the- the overall protection. And in that case, the TOA clearly has no advantage because the prefix is already subject to forged origin hijack because of the other ASes. So clearly, I mean, the answer to your question is there is no need for AS0 ROA in that case. All ROAs will be normal ROAs.
Joe: Igor.
Igor: So actually, it's a great segue. Uh, so I think that it's not entirely true that there is no advantage for the case where the prefix is routed but not originated from the same AS. If you having ROA for both will certainly protect against hijacks, but it will create a vulnerability against something like a misconfiguration. So if for some reason the system does advertise from the AS it didn't want to advertise from, with the ROA it will be propagated, without a ROA but just with a TOA there is a chance that the advertisement will be blocked by somebody who is actually watching ROAs. Uh, so that's one thing. Is it a big advantage? It's a question of- so while we have no actual deployment of SAV that uses RPKI, it's probably just a disadvantage to go and create ROAs that simply increase, like, misconfiguration susceptibility. But obviously, if we do have real deployments and ROA would help a use case and it becomes a different question and definitely it would be used. So that's what I wanted to say. And the last thing is that actually, I think Lancheng mentioned that ROA right now doesn't have any semantics about authorization of packet origination. It doesn't have it in the draft, in the ROA draft, but the way we use it in SAV, that's like a foundation of BAR-SAV, foundation of other methods, that there is this implied assumption that we can- we can infer authorization to originate packets when there is a ROA. So I think that's- that's an important thing.
Joe: Thank you Igor. We're gonna have to- Sriram, we're out of time. Sorry. We're gonna have to continue this on list. I want to give Lancheng a few minutes to go over this last draft, but we're already way out of time. I really appreciate the engagement everybody has, and we need to continue this on list. Fortunately, we don't need to resolve this right now, but we do- do need to reach a resolution, and Ron and I will talk to people about how to get to a resolution. But let's let this one last presentation go and folks can leave as- as when they need to, but I want to give Lancheng the chance. Thank you.
Lancheng: Yeah, thanks, Joe. Uh- now I'm going to introduce the updates on the intra-domain problem statement document, draft-ietf-savnet-intra-domain-problem-statement. And this document receives some comments during the IETF last call, and so now I'm going to share some of them and share our planned updates. The comments mainly fall into three types. The first type is document scope clarification. The second type is requirement-related comments. And the last type is other terminology or wording needs. Regarding document scope clarification, some participants felt that this document may have potential overlap with another inter-domain problem statement document. This is because both documents involves SAV on external BGP interfaces. This is because in this document, the distinction between intra-domain SAV and inter-domain SAV is based on the enforcement capability. And so this document involves SAV on external BGP interface but only for intra-domain use cases. But in the other document, the distinction is based on interface type. It clarifies that inter-domain SAV refers to- SAV on external BGP interface. So there is a conflict, which can make readers confused. So some participants also give us some suggestions, such as we should focus only on SAV between non-BGP neighbors in the intra-domain problem statement document, and we should simply remove the Section 3.2 which analyzes SAV at external BGP interface for intra-domain use cases. After discussion on the mailing list, we agree to revise this document per their suggestions, so we will clarify that this document focuses only on SAV at external non-BGP interfaces and remove the subsection. The first comment on requirements is about the wording issue. And the inter-domain problem statement document receives a similar comments, and we all agree to revise this document accordingly. Another comment is related to- on the use of "must" or "should" in the requirements section. And Igor said the current wording in the Section 5.1 doesn't allow for a solution that improves intra-domain SAV but doesn't achieve perfection. We do agree with that, this is a problem we need to fix. And we also believe that the intent here is likely to compare to the existing mechanisms, and any new solution must improve some key dimensions of intra-domain SAV. So we plan to revise this requirement in this way, and we will still use "must" but only used when comparing to the existing mechanisms. Our ops reviewer Zhongfeng suggests that we can add additional requirements on manageable complexity. But we believe there is already a requirement called automatic updates, which captures some aspects of manageable complexity. So we plan to revise this subsection to better reflect considerations of manageable complexity. Another comment from our ops reviewer is that the title of Section 5.5 is too general because the current title is called "security". And after reading this comment, we realized that in this section, the content actually contains two different requirements. The first one is authentication of information used for SAV. The second one is vulnerability prevention. So we agree to revise this subsection and simply split the current content into two separate requirements. In- in addition to the updates on document scope clarification and the requirements sections, we also plan to address the needs, and we thank the reviewers for their careful review. And the- the revised draft has been uploaded to GitHub. And we encourage all participants to have a review and provide feedback. If there are no objections to the revised draft, we will submit it to IETF as soon as possible. And we think maybe at that time, the IETF last- last call may be closed. Thanks.
Joe: Any comments or questions quickly for Lancheng? We are over time but I want to allow that. Not seeing anybody hopping on the queue. Thank you all very much for your time and engagement and please remain engaged on the mailing list. We're having really good work and I think we're making good progress. Thank you all. Take care, everybody.