Session Date/Time: 24 Jul 2026 12:00
[00:00:05] Chairperson: Accurately from up here. These are not that clever. I need to have the hearing aids. But if they were too clever, that would be a problem. Well, I could imagine you must have better where you have an app that tells you which conversation would you like to be listening to. Yes. Two more minutes and then we'll just have to get started. First up is well, first up is me and then the PI SAV for customer. And I I think that's the one that was asking to be remote, so it's no problem. Took you all to realize he didn't understand. We didn't need to do anything to allow you to present remotely. It just is. It just happens. That's March. I hope to be doing well enough to do that. San Francisco? I've done it I've done the South Asians before. Walking. I know. It's it's a pain, but with all the planning I can do, in some ways, it's easier than this and that I know I can sleep on the plane to help adjust the time sheet.
[00:03:02] Min Chi Huang: This time is actually less than next week. Yeah. What do you do out of?
[00:03:09] Chairperson: Yeah. It's just it's broken up terribly.
[00:03:24] Joel Halpern: Okay. Welcome to this AVNet working group. Ron, Bonnick and I are your co chairs. And of course this is being recorded. And while this is almost the end of the meeting, we will nonetheless walk through the note well. We have policies that you need to be paying attention to. They are not optional. They are not kind of. I am not going to comment and try to read each one, but it is very important that you abide by the policies. If you haven't already read through the note well, you can go find on the wiki a longer copy. You can find the underlying BCPs. These are policies we have to work with. They are very important to our functioning as a group. Please. And by now you almost certainly know the tips for the meeting. Make sure to use the QR code to sign in. Use MeetEcho, either the on-site tool if you're here or the full tool if you're remote. If you're using the full tool, make sure you're muted normally. And only unmute when it's your turn to either present or ask a question. Whether you are here or remote, when you want to ask a question, use the hand raise tool to put yourself on the queue. We will recognize you on the queue. That serves a number of purposes, so it is important. I don't anticipate us using the polling tool during this session, but we might. If you're remote, it is strongly recommended to use a headset. And when you speak at the microphone either as a presenter or asking a question, please do state your name. Don't assume we're just all going to know from the queue who is talking. Please state your name. The agenda is posted for the whole meeting. There's media co information. There's technical assistance. So we have two slides to go over our agenda. I'm not going to read it. I'm just going to give you guys a moment to look at it. If anybody sees a problem with the agenda, raise your hand and we'll recognize you if you go to speak on it. We've got the chair slides. Then there are seven presentations I believe. And this is the order we posted them to be in. And unless somebody sees a problem, we will take them in the order posted. This is the remainder. And there is one if time permits slot. If we have time, we'll be happy to have the presentation. I just can't make any promises as to whether we will. Any comments on the agenda? Okay.
[00:06:40] Chairperson: Give him the clicker.
[00:06:50] Joel Halpern: Okay. Go ahead. You control the slides and you're free to speak.
[00:06:53] Min Chi Huang: Okay. Hello. This is Min Chi Huang from. I will give the quick updates on provider interface, source address validation on your full custom call. Here's the main contents. So before we jump in, I want to revisit the motivation. What is the PSF or CC about and why is that? So as of all, we know that currently we only have tours like loose. We are careful provider interface staff. So this gives a lot of a chance to do spoofing based on loadable graphics. And meanwhile, we face it, you know, much more, you know, cyber threat outside from provider interface, especially a a support source addressed based on DDoS like that. So we need additional tours for provider interface set. So and given that a custom form, the traffic between the custom form normally will stay in the custom form. So we wanted to do something about the source spoosing custom based source spoosing. So in this draft, we propose two solution. One is we call it standalone custom column. The other one, you call it standalone plus custom, which which why it's based on feasible paths? The other one, we space it on IP paths to determine whether there's a a traffic engineering cost, you know, detour traffic going to provider interface. So let's first, let's very quick recap about the comments we raised in ITF one hundred twenty five twenty four. Thanks to eager and armor. They are basically, there are three comments. So let's go one by one very quickly. The first one is that see it seems like we have some kind of similarity with the BAR-SAV on PI. Yes. It is. So I wanna share that some bring to the group some history about this draft. If we you guys remember that the end of two thousand twenty four, we have last call about the inter domain PS. So in that discussion, me and the Nibing would and raising that will have the necessary is really about to provide the inner staff. And Joe mentioned that to us that we don't we don't we may need to also bring some rough solution discussion, not only just requirements. So I bring this idea from that time. And meanwhile, pass off also as add BAR-SAV on PI after, you know, communication community discussion like that. So so this some kind of a history. And for the differ between the two approaches, I think, why is that BI b b may, you know, have very strong connection with origin customer side, BAR-SAV and SPA, and also very strong dependency with the low and SPA, this kind of data recovery. So this may bring some, you know, problems. For example, if we don't have complete coverage of ASPI, that may will make the failure of the custom custom corn construction. And also, we may need to additional mechanism to aggregate the information from the access side to the, you know, egress side, etcetera. And also, because the strong connect dependency with the raw and SPA validation, so that will make the in the independence degree very much lower than the the the actual situation. Here, I will be giving more, you know, explanation later. So in general, I feel like that p sap p I pass up PI is kind of similar to trying to cover you know, follow the RFCs three four three seven zero five or eight seven zero four the way that one RFC fit all. But right now, I feel like this we are working the deep water, so maybe we need to, you know, different RFC tool, you know, to cover different situation, different challenges. That is my general thought. And hopefully, we can work together. Okay? And the second one is, yeah, is about, yes, t induced false positive is most important thing when we do the SSCC and SBCC solutions. So, basically, I wanna say that in this draft, we propose a kind of safe default mechanism both with SSCC and SPCC, which means we when we don't know the information, we assume that there's a detour will happen. So this kind of safety tour. And about the simulation, suggested simulation, yes. That's very good suggestion. So we separated the this suggestion into two steps. The first step, we will do the evaluation, the solution effecting effective evaluation, and then we later, we do the, you know, real the simulation. So later next part, we will cover this part. The third comments is about the yeah. Yes. That's topology suitable AS is this actually is a very good, you know, comments. After that, we add introduced a new metric in the draft, which called independence degree, which means we can calculate how many properties can be in the block list over the overall properties in the cut the custom. So by by this way, we can give initial, you know, sense to the operators that what kind of solution is will fit them more. Okay? So this quick recap of the comments. And then, yeah, as just mentioned, did a solution effective evaluation. This is based on the BGP RIBs from road views, libraries, and also some database from KADA. So we evaluate that what would be like if we have FCC and APCC running in the Internet. So the left chart shows that the independence degree is quite, you know, bound into, you know, shut shallow customer, which means we if the customer devs getting higher, the in independent degree will, you you know, get degrees very fast. And overall, only about 20%, actually less 20%, customers customers course that the dependency degree can achieve over 80% and about 50%, you know, the independent degrees lower than the 40%. So this is why we want introduce another solution which called SPCC. So we also do some, you know, evaluation about a p c SPCC, although the sampling number is is quite you know, quite small because the current vantage point of the road views and is is is not so much. But it it it shows that if we do SBC, SPCC, the independent degree will, you know, get much better than SSC. And then the here's the main aspect. Actually, we have three part one is that we just mentioned. We introduced the metric independent degree. And the second one is that we want to make sure that this is about a solution framework. It's not about how to implement it. So we separate the procedure with the requirements, but we avoid to try to step in the implementation. And then the third part is we add an additional session to describe how to refine the, you know, several result based on the circle. So here's some example about the procedural requirements. So for SSCC, we highlighted three three requirements. First of all is partial privacy information, which is in is critical for us to, you know, to identify the custom, you know, to all all members. And then about the provider information and about the most information then. For SPC SPCC, we suggest a model that cause a diffusion query model to, you know, talk make the top AS to talk to the customer AS and to get the information about where is there, you know, or or any other information may may be required for, you know, like like, for example, partial transit or or more or whatever.
[00:17:55] Chairperson: You need to wrap it up. Okay.
[00:17:57] Min Chi Huang: Sorry. We
[00:17:59] Joel Halpern: have time for one question if somebody wants to put themselves on the queue. Not seeing any, we will move on to the next presentation.
[00:18:10] Presenter: I can ask a quick question.
[00:18:12] Joel Halpern: Go ahead, Sriram.
[00:18:14] Kotikalapudi Sriram: One thing that would be useful is there are, like, 1,300,000 or so I p v four and I p v six prefixes throughout the Internet. And on the provider interface, typically, you would receive the full table. All 1,300,000 routes for all 1,300,000 prefixes. So now you're trying to eliminate some of them by by by some mechanism. So it would be interesting to know what percentage you are able to eliminate. How much is the reduction in the in the size of the staff table compared to the full table?
[00:18:57] Min Chi Huang: I guess the solution effectively evaluation will give some answer to this part. How basically, this depends on how how how large the custom quorum it is and what kind of, you know, solution you you you approaching. For example, if for s a p c c c, normally, almost all the prefix in the custom quorum could put into the perfect list. But but if we just let the the topology talk, so seems like no no so we are fitting the mean, I just I mentioned that only 40, you know, less than 20% of customer can get, you know, higher interface higher independence degree like that.
[00:19:57] Kotikalapudi Sriram: Okay. Yeah. We can discuss it some more later.
[00:19:59] Antoine Fressancourt: Sure. Thank you.
[00:20:12] Kotikalapudi Sriram: I'm Sriram, from NIST, and this is joint work with, Igor, and, Doug Montgomery. So today, I'm going we did a couple of updates since we last presented it, parts of version nine and then version 10. I'm going to give you a summary of, some of the changes we made, the new things that that we have added to the draft. The outline of my talk is along the lines of first, we talk about intra domain component of Barsav briefly. My security considerations where where we talk about the coordination between routing security and SAV. So we expanded the security considerations to to to to discuss this this coordination, how the routing security helps us with SAV, and that makes SAV more robust in turn and reliable. Then we talked briefly about ROWA and ASPR derived deny list to assist with the prefix filtering. I'll talk about the connection between sav and prefix filtering as we go along. And if we are able to to use the deny list to to make the prefix filtering more accurate, then this will in turn reduce import improper admits in the SAF table. And we finally, I'll talk about the dual dual utility of bar SAF for SAF and prefix filtering. So in the intra domain solution component of bar-sav, I'll quickly run through this. This is a long list, but the the idea is that when there is a prefix user in the intra domain, there is no BGP. The the the prefix user or the customer is directly connected to an ASR without BGP. And in that case, the the prefix user should create a ROVA as it's always recommended. It and it helps with the SAV at ASS one or more hops away from the origin AS. However, for the Origin AS itself, the local configuration information takes precedence over the over the ROAA. So that's important. We I will see that in an example on the next slide. The Origin AS the the Origin AS would originate a route based on mutually agreed config information with the customer or the prefix user. And it will also either allow or block a prefix for source address validation, based on the config information as well. And the ROVA for the prefix, it must not be utilized, by itself for route announcement at the Origin AS, except for egress ROV. And the reasons for that are, there may be multiple prefixes in the ROVA, or a max length present. So so prefix user must inform the origin AS about the desired config info information. And based on that so it the the configuration is information is about which prefix must be configured for routing announcements and which prefixes must be allowed or disallowed for SAV. So it's at the in in the entire domain, it's mostly configuration information driven. We cannot use that over by itself. So here's an example. The, the customer has a prefixes P23, PSlash23, PXDash24. Oh, it's already, three. Is it three minutes? Okay. Sorry. So the PSlash 23 is actually divided into two prefixes, PX24 and PY24. They have registered ROWAs just in case sometime down the down the road if they need to announce the more specifics. And there's a q slash 24. They also want that announced. So the the the aggregate p slash 23 and the q slash 24 are announced, and that is configured based on customer's configuration information. And so so those two by default are also included in the SAF table. They would be permissible. Because they are routed, they would be permissible for SAF as well. Additionally, the z slash 24 is also allowed in this in the sav table according to the customer's request. So in this case, the customer happened to go ahead and include z slash 24 also in the ROVA because they want to be prepared, just in case they they need to announce that prefix also in the future, but they are currently using it for, SAV. By doing this, a s one, doesn't have to look at the ROVA on the in on the ingress side, on on the customer facing side. It just uses the configuration information to do the SAF. Other ASs, one or two hops away or multiple hops away from the this AS would be would would have the need for the ROVA information. They would go by the ROVA for the SAP. Security considerations. I understand that, Joel had a discussion with Lan Chang and Igor sometime back, about security for the TOA. And, in that context, Igor and I talked about it, and we we thought that, we should also, try to address Joel's questions regarding the security, for, SAV in general, the the intra domain SAV in general and Barge SAV in particular. So here, we should recognize that the security for Barge SAV security and robustness for BarSav are strengthened by supporting mechanism for detecting and dropping BGP routes that are misoriginations or leaks. And for that, we have a variety of mechanisms that are well under development in inside our ops, the ROWA and the ROV, the ASPA ASPA verification, and the OTC, RFC ninety two thirty four, and use of prefix filtering by the operators. So by by these mechanisms, an update can be marked as ineligible for routing. And if if that's the case, that those routes would not be considered and put into the SAF table. And by doing that, we reduce improper, admit. And, so the primary bar-sav is able to achieve, is it has the ability to achieve zero improper block, which, which significantly bolsters operators' confidence in deploying the solution. So some improper permits, can happen, and they are they can happen definitely during partial deployment. And this remains an operationally acceptable trade off. So even in the absence of route leaks and other AS path attacks, etcetera, where we have where we're we might be worried about improper admits. Even in the absence of those attacks, improper admits can still occur due to partial deployment. And as the deployment increases and it it kind of transitively progresses upward in the hierarchy, then there is a collective benefit for everybody and the improper permit significantly, drop down towards zero. So here's an example, where we have a customer cone, a s seven is looking towards a customer a s six and this customer cone, they are in that customer cone, there is a route leak. And if that and that route leak causes a s six to believe that ZSlash 24 is is a genuine prefix coming from the from from one of the customers and it includes in the staff table and because of that, will have improper permit. But if we have route leak detection mechanism in place, as per OTC, then this route leak would be detected and then the improper permit would be mitigated. So there are many features of routing security. I don't not showing all of that here. ROV, ASPA, OTC, prefix filtering, all of those combined eliminate these route leaks or hijacks, and that would that is what contributes to making SAV more accurate, in terms of improper admit. And the improper blocking is well taken care of in ParSav for the scenarios of our interest per the pro problem statement because we have ROVA and ASPA. We make we make very effective use of that. So we we can also have a ROVA and ASPA derived deny list to assist prefix filtering. In this example, on the left side, we have AS one, AS two, AS three. They are originating prefixes p one, p two, p three. And the ASPA and ROAs are such that, we are it confidently tells us that these prefixes are single homed at those origin ASS. And also each of these, ASS has, only one provider in its, ASPA. Because of that, we know that these prefixes don't cannot come by any other on any other interface. And, therefore, on another interface like with a s five, in the SAV table no. I I would say in the, prefix filtering, you can block p one, p two, p three. So so if they happen to come from a s five, they would be eliminated, from routing consideration. The next thing okay. That's good. I'm on the last slide now. Here, I just want to make a comment. This is a figure that, often used for Barsav, how it tries to capture all the prefixes in the customer cone to make the improper block equal nearly zero or actually zero if if the ASS follow the recommendations of creating ROVA or or creating ASPA. So, I want to go, yeah. So so the same, technique can also be used to construct, the list for prefix filtering. So in fact, they would be identical. So in that sense, BarSav can also be used for for the purpose of prefix filtering. I can stop there. Thank you.
[00:31:00] Chairperson: Go ahead, Lan Cheng.
[00:31:01] Lan Cheng: Yep. Lan Cheng from lab. Thanks for the presentation. And I noticed there is a new intra domain solution, yep, component for BAR-SAV. And I also have a intra domain self draft. And I am glad to see that both of our solutions are largely aligned. We share the similar direction. Yeah. So maybe we can talk after meeting.
[00:31:28] Kotikalapudi Sriram: Yeah. Definitely. Like we discussed the other day, I'm very interested to to Yeah. Yeah. To discuss the idea you have with with you, and we can combine the ideas and and see where something may be lacking, and we can use the use the set of ideas together to to to come up with the conference comprehensive solution.
[00:31:49] Lan Cheng: Yeah. And I want to mention that there must be an important theme missed in your presentation. So as assume in this example, there should be two rows because the prefix p and prefix q are belonging to the belong to belong belong to one prefix holder, but prefix they may belongs to another prefix holder. So, actually, they are two ROAs. Right?
[00:32:15] Kotikalapudi Sriram: Not necessarily. It's one cuss oh, no. One customer, they have certificates for all these prefixes. So they can create oh, because
[00:32:25] Min Chi Huang: Yes.
[00:32:25] Lan Cheng: So you assume the prefix holder is the customer. Right?
[00:32:29] Min Chi Huang: Right.
[00:32:29] Lan Cheng: Okay. I got it. And another thing Yeah.
[00:32:33] Kotikalapudi Sriram: In case right. You may be right. In case one of the prefixes is allocated by a different provider Yes. Then they would have two.
[00:32:39] Lan Cheng: Yes. And another important thing is that in Lua, it is the payload includes AS number, not the customer identify. So we still need the customer to tell to the operator of AS one. If the AS one have multiple customer network with no AS, so it can identify which customer network actually you can use the prefix state.
[00:33:05] Kotikalapudi Sriram: Yeah. I was assuming the interface has an ID. Yeah. Maybe.
[00:33:08] Lan Cheng: Yeah. Or something like
[00:33:09] Kotikalapudi Sriram: Operator goes by the interface ID.
[00:33:11] Lan Cheng: Yeah. That okay. Yeah. That's my comments regarding the intra domain. And I I also have a comments regarding to the prefix filtering. So could you turn to the page page eight maybe? Next. Yeah. Yeah. Yes. So I'm a little bit confused about the usage of the deny list. So in this example, if the three AS, a S one, s two, a s three, all of them have ASPA, And the prefix one, prefix p one, p two, p three all have rules. So if a s four received a hijacked route or received a leaked route from a s five, which is related to the three e s or the three prefixes, a s four can use our way or as part verification to detect the hijacking or root leaks. Why we still need a denial list? That's my concern. So I'm a little confused.
[00:34:13] Kotikalapudi Sriram: Partial deployment. Like, the underneath a s five, there may be partial deployment of ASPA and ROVA, and somebody leaks, say, p two. So so you are saying that yeah. On the left side, there is full deployment. Yes. That is why So
[00:34:31] Lan Cheng: a s four have this information already. It can just detect it by our way and as as per verification. So in this case, I I don't see the value of another denialist.
[00:34:44] Kotikalapudi Sriram: Yeah. That end there is still a possibility of maybe forged a part segment hijack or something like that. But your point is well taken. We can we'll I can think about it, and we can together think about it some more.
[00:34:58] Lan Cheng: Yes. And and another thing is this design is mainly for BGP prefix filtering. So I'm not sure if SAVnet working group is the most suitable place to discuss with this design. So I would suggest you can share this to the maybe to the guru working group.
[00:35:16] Kotikalapudi Sriram: We could do that, but it helps SAV because any any anything you do to to eliminate bad prefixes from getting into the routing table, that helps SAV because SAV relies on the on the ribbons. Right? So any prefixes that you mark as ineligible helps sav.
[00:35:36] Joel Halpern: Lan Cheng, I think we need to take this to the list. I'd like to let the other three people ask the other two people ask their questions, and we're way over time already. Antoine, you're up.
[00:35:50] Antoine Fressancourt: Antoine, you're a little bit slow. Yeah. I I sort of agree. If if if you go to the, which one was it? I think the third slide. I'm confused about your use case here. This one. Yes. So if I'm building SAV and the slash 23 has a ROA or it it it has a route object. I'm doing so for the slash 23 or longer for a customer. Right? So in in the slide before, I don't understand your statement. What was it? That the the local configuration takes precedence over the ROA because he should have had a ROA for the slash 23. Right?
[00:36:37] Kotikalapudi Sriram: Yeah. That's in the ROAA is created, but the customer doesn't want, the p x yep. So p 23 should be announced, and and it has ROVA coverage. But the customer currently doesn't want to announce the sub prefixes of that prefix, p x 24 and p y
[00:36:58] Antoine Fressancourt: He announces it to a s one. But he does announce it to a s one.
[00:37:02] Kotikalapudi Sriram: It announces the aggregate, but not the more specifics. So it has to wait. It has to let the customer tell you tell the the customer has to tell the operator that p slash 23 must be announced, but not the more specifics even though they are in the ROWA. So that is a configuration agreement between the customer and the operator.
[00:37:24] Antoine Fressancourt: And he doesn't announce them. Right?
[00:37:26] Kotikalapudi Sriram: Doesn't announce the more specifics.
[00:37:27] Antoine Fressancourt: It would not. So that Right. Then what what's the problem?
[00:37:31] Kotikalapudi Sriram: The no. They're not at another time,
[00:37:33] Joel Halpern: if I
[00:37:34] Kotikalapudi Sriram: think it is they want to it for some reason.
[00:37:36] Joel Halpern: Need to take it to the list.
[00:37:37] Kotikalapudi Sriram: Okay. I I we can just offline.
[00:37:40] Chairperson: Please.
[00:37:42] Min Chi Huang: Hi. This is from.
[00:37:45] Kotikalapudi Sriram: I I will give a
[00:37:46] Min Chi Huang: very quick comments about the use ROV, ASVA validation, or OTC, whatever, essential to enhance the, you know, accuracy about the the perfect list. So first reaction to me is that this may be, you know, we step in another domain that is about the, you know, validation of routing security. And then and also, this mechanism may introduce overhead, not, you know, some some overhead. And we may need to think, what if the system already ran this routing features, routing security features? And then what we can do? And then the other thing is that in the period of incremental deployment of the this kind of, you know, route security objects. So if we use this strong strategy, that may make the, you know, like, independence degree very low. You know? Because if, for example, ASPA, if some kind of information missed, So a lot of prefix maybe is included. That's my comments.
[00:39:02] Kotikalapudi Sriram: Yeah. Regarding your first comment, we are not doing ASPR ROV verification as part of BarSav. Maybe you misunderstood. As per verification, ROV verification, they are all they're going to be done for in the routing for routing. And all I'm saying is that, Joel's question about how do we know that this is secure, it's because routing takes care of route eliminating route leaks, hijacks. That's why we we can rely on that to make SAV more act SAV becomes more accurate because of that. Yeah. Your second later part, we'll discuss it offline because we are short of time. Thank that's good. Thank you.
[00:39:47] Presenter: Hello, everyone? Is my voice clear?
[00:39:50] Joel Halpern: We can hear you, and you have slide control. Thank you.
[00:39:54] Presenter: Okay. Thank you very much. Today,
[00:39:57] Kotikalapudi Sriram: I
[00:39:57] Presenter: will introduce our two SLA drafts. The RPKI profile and its use for bootstrapping intra AI source address protection. And before this meeting, I have presented this in the side drops working group because I want to item in the RPKI system. But it's the question is about source address validation. So this meeting, I request a time slot here and represent this to our group. Let me start with the deployment. Sources drive validation benefits many networks, but each AS pays as has its own cost. So deployments in the past is is low, and we are all trying to solve this problem. So we propose a voluntary bilateral service. The subscriber selects the protective prefixes and computes the predecessor state for a specific provider. If the provider accepts, it installs validation rules and filters spoofed traffic for the per for the subscriber. So deployment can begin with one AS pair and grow incrementally. For discovery and authentication, we use RPKI instead of building a new trust system. And an SOA is assigned to service profile. It advertise advertises stable information such as the service role, endpoint, protocol, and the channel public key. And the dynamic criticizer state did not public published in RPKI, and publishing an SOA doesn't create a service relationship. RPKI pre provides a trusted trusted bootstrap and but not loading states. And based on this SOA object, we build architecture. It has two tiers. The first tier is API s SOA and which authenticated the profile endpoint and the key. And the second tier about this is a private TRS channel using Sabre. Once the provider accepts the relationship, this channel carries the provider specific predecessor sets and the freshness information because every provider is in different places in your Internet, so they have different predecessor asset. And then snapshot sent to the full state, and they're trying to update it and withdraw, remove it. And if we have a a serial gap, we can use the resync that handles missing updates. So the stable trust remains in RPKI while dynamic state, we have changed it off RPKI to make it fast and reduce the burden of RPKI. So next, introduce the workflow. It has five steps. Both sides can publish their profiles. Profiles have their role and other information. So they can discover each other by the profile and validate the SOAP object through API or it has its own process. The provider then checks compatibility and local policy before accepting the relationship. If the provider choose to accept, they can establish establish an TRS channel, and the pure key must match the key in the validated SLA. And finally, the subscriber can synchronize its state, and the provider can install or update the rules. And the synchronized state is applied only when within an authorized prefix scope. And that scope, now we want it to be provided by ROA and TOA maybe in the future. So now there are there are four outcomes. Spoofed means the incoming predecessor is outside the fresh set, and the path consistent means it it is inside the set the set. However, this checks only the path, only the cam incoming direction, but it doesn't prove the source AI is authentic. And not found means no accept accept relationship or authorized scope applies to this prefix. And then state unavailable mean that the relationship exists, and the state is missing or stale. And next is the relationship between the existing subnet mechanisms. First, like our object s ISPI, it can also show some support to fund each other. But we have the difference because we are different rules. Some, yes, are the provider and some are the subscriber. They share different rights and do different things. The provider use the rules to filter traffic, and the the subscriber can compute the predecessor and tells the provider. And and for sure, the service will be char will be charged. So the provider also have the encouragement. And another one is behind the SOA, there is a full algorithm of how we compute the the predecessor sets. And that step will be put in the future version of this draft. And for pre prefix authorization, SOA uses the scope defined by TOA or ROA, and they are complete complement to each other. It doesn't redefine the ownership. And another draft assay capability and other s o s a v methods, they can also become complementary to our drafts because the final the final rules may be in the shape of the same I say the capability. And then the predecessor state, it may come from routing data or local computation. So I saw it on distributes the provider specific route through the private channel. And in summary, SOM may contribute four things. First, it it provides a direct protection outcome through a bilateral relationship. It is very friendly to incremental deployments, and it res resizes RPI to authenticate the result and endpoint and some other things. So we can trust each other, and then it's distributed dynamic predecessor state privately. So this state is not published to all of the Internet because some may not want to make it public and keep it keeps it fresh. And it is designed to work alongside with SSPI, TOA, ROA, and other asset capability and other existing asset in the methods. It doesn't break anything. Our main question is, is this separate between stable ask AbiCare bootstrap and dynamic private step state useful for at some nights? And that's all. Thank you. Welcome for that question and comments.
[00:48:52] Joel Halpern: Antoine, I assume your hand is still left over from the previous one. Oh, okay. Go ahead. And anybody else who wants to speak, put yourself on the queue, please.
[00:49:04] Antoine Fressancourt: I'll toss you at Liberty Global. Thank you for this. Interesting. I have a general observation to make and not perhaps a question to ask and perhaps we could we can talk later in the hallway. But I get the impression that we're getting we're seeing a lot of proposals. You know, there's TOA, there's SODA, there's SOA to circumvent existing routing rules. Because the the the the the there are all sorts of corner cases where we're trying to find a solution for a corner case, and I sort of feel that this is a same one. And one thing that we need to consider is we're already having a problem for people to sign their ROAS, to create their ROAS and their ASPA records. Now if we if we get all sorts of security related, records that people need to sign, I'm afraid that it becomes so incomprehensible for simple networks, you know, of what record should I use.
[00:50:14] Joel Halpern: An interesting point. Please make that point to the list because I
[00:50:17] Kotikalapudi Sriram: think Yes.
[00:50:18] Antoine Fressancourt: I will do that. Just want to make you up to it. If you're if you're somewhere here, I see you have a t shirt, Speak me later in Norway.
[00:50:24] Joel Halpern: Nangong, go ahead.
[00:50:26] Nangong: Yeah. That's a little comment. Nangong from Huawei Technology. Will I mean, will the SOAR object the records be dynamic in the practical networks?
[00:50:45] Presenter: Now the in information in the store object is relatively stable if we compare it to the older versions of this draft. Because this is the first time I present it in our group, so it seems stable. It only has the bootstrap information of the AS.
[00:51:12] Nangong: Okay. Thank you.
[00:51:13] Presenter: Thank you. Yeah. And I I said one sentence for the upper question is, so and the and the other objects, we we can register one object for one use. If we don't need to protect or get get other service, we can just not bootstrap it. Yeah. That's that's what I think. Thank you very much.
[00:52:03] Joel Halpern: You're up now. You don't need to put yourself on the queue. Just come up to this microphone. I'm sorry. Just a moment. I need to switch to the correct
[00:52:35] Min Chi Huang: okay.
[00:52:38] Chairperson: There I see. Want the you intro domain source.
[00:53:14] Joel Halpern: My apologies for the delay. There we go. I'm sorry for the delay. You have slide control.
[00:53:43] Presenter: Okay. Thank you. Thank you very much. Today, I'm here to introduce the main updates on our draft about inter-domain source address validation based on AS relationships. And, firstly, I hope to have briefly introduced our RB scheme from man design and the previous works to introduce introduce it. And, firstly, we use the AS relationships to abstract the routes for the inter-domain source address validation and to brief to briefly simplify the design of the design of the architecture. And we set the validation router, which has actually the border routers for exchanging and generating the ASN set rules for the for the generation of the rules. And then they use we set AS-IP prefix mapping server for maintaining the mapping for ASN IP prefix. And the validation router, it can use the mapping for ASN to IP prefixes and to generate the IP prefix sub rules for deploying them in the validation router and to start the prefix filtering. And the original idea of our scheme is based on the pro the proposed RFC five two one zero in 2008. And we have finished our draft and make presentations on the on our draft and its main updates in several previous ITF seminar working group meetings. And today, we hope to introduce the main updates between the from one IETF one two three to to nowadays. And after the pre previous presentation, we have received some comments about our draft and our updates and our design. Firstly, the comment it's actually the comment from APNIC meeting, and one researcher told told us that our scheme discussed many scenarios but lacks the discussion about inter domain SAP scheme in the typical complex scenario that it it was the Internet exchange point, XP. As we add add discussion about the R-B SAV scheme in the IXP scenario in section six and to discuss how the scheme handles AS connections and AS relationships in this in these scenarios. And what's more, some researchers told and within our writers, we found we hope to learn more detail details of the algorithm and the calculation process in the scheme design. So we added more dis introduction to our architectural design and the actual and the the data structure and provide more detailed procedures of our inter domain source address validation scheme, R-B SAV. So the main updates. Firstly, we add discussion on how our scheme R-B SAV handles into domain SAP in Internet exchange point scenarios in section six. And what's more, we also add descriptions of the data structure in our designed AIMS design and some detailed procedures for how the AIMS maintains the mapping data and how it responds to the various queries for the mapping in section four. And correspondingly, we also add a term for the add term and introduction for the AMS data structure in the terminology section. And about the main updates on our AS-IP prefix mapping server, We hope to we hope to add more abstract description and introduction to our AIMS. No matter it is implement implemented based on existing mechanisms like API or other designs, or it was it is implemented it was designed independently in some small networks or for the big big networks. So we add more dis discussion and introduction to the AIMS architecture itself. Firstly, we design we we introduced the main data structure, the AI prefix mapping table. It should record the mapping from the ASS to IP address prefixes owned by ASS. Also, it should maintain the mapping and offer corresponding IP address preferences of ASNs to the validation routers when the route when the validation routers send the query to it. And the the major major functions which the AIMS should should handle that we we we we describe it from the ad mappings, delete mappings, and response to a curious. But when about adding mappings, that's yes. We briefly we briefly describe it that abstractly that the AS sends a message to AMS carry ASN and new prefixes. And no entries then insert one. And with the entry, the AMS should add a record for the ASN. And when deleting the mappings, the AS also sends message to AMS carrying the ASN and all the prefaces. And the the AMS deletes the record for the ASN. And if the entry has no record, it should be deleted. Actually, the description, we hope we we did add it here. We hope to describe and introduce it more abstractly no matter how it is implemented in the actual actual internet actual networks. And the third one the third important procedure is that the curing prefaces with ASN. And the VR validation routers, they send the message to s AIMS carrying its needed ASN, and AIMS researches for the entry for its data and in its AS prefix mapping table and then replies the query results it to the query via validation router. And based on the act based on present design of network security the root security based on the RPKI. And we we can find that the original data, which the AMS should maintain, that which is the mapping from SSN to address prefixes, it can be provided by the raw objects maintained by the API repository. And with the help of the relying party, it's which which pulls the data which pulls the we need the needed raw objects data from remote to local cache. And it we can make use of in most of times, we can make use of the the raw objects recorded and pulled to local caches. And so that we in based on the API, the ANS can be implement can be designed in like the big picture in the picture. That's the original data, which should be maintained, and the add delete is response and the API itself is responsible for the maintaining of the original data and for the adding or deleting of the re records. And an extension to the EMS function, which was designed to which which was designed and ex as an extension to the API itself. And we can we can design it to generate the mapping. And we based on the relying party and the API repositories, it's to offer the to offer and respond to the mapping query from the validation routers and to provide the ASM the prefixes for the ASMs. And based on this, we can make it more clearly. About in iAXp, we found that we found that it's actually that the connected validation connected routers from different ASCs. And to reduce the number of the B2B sessions, they usually set router servers. Actually, the route the RIS clients, they advertise network to the router server, and the router server forwards the information to the its connected RIS clients and without forwarding the traffic. So that's we discussed the R-B SAV in I x I x p that we treat the typically I x p scenarios and several fully connected peering. We wondered that, are there any complex scenarios? And the main answer is yes. That's maybe just some complex scenarios are too complex to be discussed in our draft as we mainly discuss simplified scenarios. So we will apply the current implementations to more scenarios to optimize it and for more cases. And still, we will insist on refining the R-B SAV system. And that's all. Thank you.
[01:04:15] Joel Halpern: K. Mengling, you're on the queue. Make your question a little fast, but go ahead.
[01:04:22] Presenter: Oh, sorry. I didn't mean to join the queue, but I don't know how to. I don't have a questions. I think it it's a good presentation. Yeah.
[01:05:00] Joel Halpern: Okay. You have slide.
[01:05:02] Nangong: Okay. Good afternoon. I'm from Huawei. I will I'm to present an interdomain solution. In the last last year, I presented this draft and received some comments from Jeff Hudson and eager. And after that meeting, we updated this draft. We made a significant update, so I will introduce the solution from the beginning. We propose our main idea based on a key observation. That is the accuracy of the customer call of the source AS and the prefix set built by the validating AS is no larger than than those built by the source is. So in this figure, I will is illustrated that how do we get the observation. The validating is kinda run some internal domain our mechanisms, like EFU, RPF. And the customer call of the source ASR and the source prefix set can be built on the customer interface. And then the source prefix allow list will be built based on the CC and the the prefix set. And suppose we run a similar algorithm on the source AIs, it can build a relatively more accurate call and a prefix set. This is because some policies applied on the source prefixes are only visible to the source AS. So based on the observation, we propose that we can make the source AS to advertise the call and the prefix set locally observed to the validating AIs through SPA messages. And the the validating AIs can be combined local information and the information in the received SPA messages to build a more accurate allow list. And to reduce the payload size, the Source AIs can just advertise the diffcom compared to the BGP updates. And there are two usages of SPA. First, SPA can be used for supplementing source prefixes. In this example, there are two hidden prefixes es that is p one and p two in the customer call of a s two. And a s two and suppose we use a EF URPF, so allow list at the customer interface of a one will include will not include the p one and the p two, so there may exist improper block problems. If we deploy SPA on both a s one and a s two, s two can either has the hidden prefixes of p one and the p two to s one. Then the allow list can include a p one and a p two so the improper block problems can be eliminated. But in this case, s two may not aware of the hidden prefix directly. But s s a can deep choose to deploy SPA, and the other one has hidden prefixes to s two. And then s two will regenerate a new SPA message, and this message will be probable be either hazard to s one. Then finally, the final allow list will include the p one and the p two. So another usage of SPA is to exclude the source prefixes. Here is an example. ASP. Suppose a p one and p two are authorized to ASP, and ASP has a lower record that includes both p one and p two. Suppose we run an inter domain, so mechanism on a s one. So allow list on the at at the customer interface will include p both p one and the p two because a s one can get the ROA data from the published point. But in this case, p one is full trans data, but, however, p two is partial trans data. P two is only Edward has the within the call. So in the normal case, a s two will not route traffic away the source of p two to a s one. In so also, deploy SPA. S two can use SPA messages to s one, and then s one can exclude p two from the allow list, then the improper permitted problems can be eliminated. Here are some security considerations. First, the BGP session should be protected using some maybe existing mechanisms. And regarding to the content security, SPA should be propagated one hop. Suppose we want to the information of SPA be propagated through multi hubs, the intermediate AS should regenerate a new SPA message, and the the message can then propagate it to the next hub. In this case, there may exist a stress to the SPA content. Source but Source AS should have little incentive to intentionally either has incorrect or malicious SPA messages. First, this incorrect SPA messages will will directly impact the traffic from forwarded from s two to s one. So there if for so source a s either has false SPM messages, there is no benefit to the source a s. And second, suppose Source AS want to falsely include a include a mass prefix in the SPA messages, would need to support that as a conventional DDoS attackers collude with operators of the source AS, but it's not the euro case. And so when to pay attention on the unintentional false SPA messages to avoid unnecessary incorrect information. And, finally, if the mechanism is deployed within a single trusted domain, the aforementioned many of the security risks can be mitigated. Okay. That's all. Thank you.
[01:12:43] Joel Halpern: Any questions? Not oh, well, there comes one. Go ahead, Andre.
[01:12:50] Antoine Fressancourt: I'll ask you a little bit global before you before Joel says me to send it to the list. One question. Who authorizes the SPA records?
[01:13:01] Nangong: Who authorizes what what? The SPA messages. The SPA messages is propagate the one hop.
[01:13:10] Antoine Fressancourt: Yeah. So if they are so if I'm a hacker and I'm downstream in ISP, I can say, hey, ISP. Please accept me to announce 8888 to you, and he accepts it?
[01:13:21] Joel Halpern: There is there is I think this needs more discussion. You are absolutely right. As currently proposed, there is no authentication associated with the SBA.
[01:13:30] Kotikalapudi Sriram: Okay.
[01:13:31] Joel Halpern: And it being one hop is not enough protection for multiple reasons. So we need to take that to the list. But you're absolutely right that it's an important question.
[01:13:43] Li Bin Liu: Go ahead, Li Bin. Li Bin Liu from lab. I I I have noticed that the updates has already exclude the big information in BGP from their SPA message. So but, you know, the work group already proposed various data information sources such as row and toe. So I'm not sure if SP a also exclude the certain other information from the data sources. Of course, this may depend on their some mac mechanism itself.
[01:14:23] Nangong: Yeah. We we we will consider those source of information when generating the SPM messages. We can discuss in detail of that. Okay. Thank you. Thank you.
[01:14:42] Joel Halpern: Okay. Lan Cheng, you have the last two presentations. Sorry. We're a little behind, but your first one is up and let me know when to
[01:14:51] Chairperson: set up your second one.
[01:14:57] Kotikalapudi Sriram: Okay.
[01:15:02] Lan Cheng: Hello, everyone. From lab. Today, I will present the updates on intra domain source address validation architecture. Okay. So first, let me briefly introduce the context for this update. The updates are can be group grouped into three categories. First, we align these documents with a latest version of intra-domain SAV problem statement, especially in the definition and scope of intra-domain SAV, as well as related terminology and some examples used in this document. Second, we clarify the common architecturalcom components as well as the information flow for several generation in the intra domicile area. And we also expanded some incremental deployment considerations and added some new considerations for operational visibility and some and for security and privacy. As defined in the intro domicile problem statement documents, intro domicile for an ES validates source address of data package originated from this ES directly or indirectly. It means this intra-domain SAV is applied at external interfaces facing attached entities that are not neighboring ASEs. They can include customer network with new AS and directly connected hosts, and so at other interfaces or out scope. As for the conceptual components for intra-domain SAV architecture, there are three important parts. The first part is the information sources. Information sources for intra-domain SAV comes from sources within the ES. It can come from the routers within the ES or from an operator managed system within the ES. And each of them can provide self specific information, routing information, or both. And then the SAV agent, which is a logical function, it will obtain those information from the sources and generate the sub rule according to the algorithm. And an important note is that the SAV agent can be implemented in router or can also be implemented in a server controlled by the AS operator. And then it will install sub rules in the sub table at the specific external interface. The routing information describes the reachability and the forwarding behavior. It may include the read or fib information for a router. It it may learn this information from dynamic routing protocol in the ES or from some static loads. It can also contain some configuration information for load origination. Okay. And as for SAV-specific information, is the information dedicated to several generation for intro to MSF. One important type of self specific information is the association of multiple attachment interfaces and the same attached entity. With this information, it allows some mechanism to consider the context of the attached entities source authorization across all relevant interfaces, Instead of only consider the available interface available information at a single interface. Another important type of self specific information is the source prefixes that an attached entity is authorized to source traffic even it doesn't advertise that rules to the AS. And when sub specific information is not locally available to the SAV agent, we need a mechanism to delivery. Yes. So the routers or the operator managed system within the AS can provide the sub specific or route information through through this delivery mechanism to the south agent in another router or in another server. Yeah. That's it. And this delivery mechanism may may may maybe can reuse an existing mechanism or protocol to achieve it, or or maybe we need to expand we may may need a extension or define new. We currently don't know. So the specific design of such delivery is outside up out of the scope of the document. But in this document, we provide some design points that need to be considered. The delivery mechanism must consider to define the information semantics, encoding way, and transport or management's method, and the update behavior and error handling. Yeah. This this this part, SAV agent and the raw generation part is unchanged. Yes. So I will just briefly introduce them. And the SAV agent is the logic logical function, and there is also a conceptual data store for information used. It's called cell information base. In addition to the raw data, it may also contain the metadata, such as information sources and its freshness. As for the raw generation algorithm, it's mechanism specific, so it should be defined by the specific mechanism instead of in the architecture. As for the data plane enforcement, the architecture recommend we can use before we use the strict drop in policy for packets that are identified as spoofed or email it, we can use some conservative deployment options, such like we can choose to permit, but with monitoring, with logging, just as described in another document, the general sub capability document. And we believe existing intradermal cell mechanisms, they are worked in a single rupture, and they consider information towards a single interface. So it may not fully represent the source address authorization context of a test entity. So, especially in particularly in the scenarios of asymmetrical routing and hidden prefix. So with the additional contact from self specific information, some mechanism can know more information and know have a more complete view of the context across all attached attachments, and as well as the hidden prefix information. So we can achieve fewer or even no improper block and achieve fewer improper permiss. Yet to summarize, most of the updates are textual updates to make it aligned to to the intra-domain SAV problem statement. And then we also clarify the architectural components as well the content of subspace information and explain why with this subspace information, we can improve the accuracy. Thanks.
[01:23:10] Joel Halpern: If there are any questions, put yourself on the queue promptly, please. Go ahead, Sriram.
[01:23:21] Kotikalapudi Sriram: Regarding, like, hidden prefixes, why should there be hit any hidden prefixes? The customer is directly this is Sridam, NIST. So the customer is directly connected to the AS, and the AS operator requires the customer to to to to through a contract or whatever, declare what prefixes need to be announced and what prefixes should be used for Sav in case they are not announced. So why so there should be no possibility of a hidden prefix.
[01:23:58] Lan Cheng: What you said is is just the the hidden prefix, I mean. So it's just maybe it's just issue of the name name. So what I mean is just the information about the customer should tell the operator what information what prefix it is isn't it is it can be used to source traffic, but not advised.
[01:24:20] Kotikalapudi Sriram: So no other special mechanism would be required. The customer just informs the Yes. Provider.
[01:24:26] Lan Cheng: It should inform the provider. Mhmm. Yeah. That's it. That's what what what what what we call hidden prefix in this document.
[01:24:33] Kotikalapudi Sriram: Yes. I would call that just configuration information that needs to be shared between
[01:24:38] Lan Cheng: the customer and Yes. It can y configuration.
[01:24:42] Min Chi Huang: Hi. This is Miching Huang. I'm wanting, as we know that the most challenging part besides the direct candidate host is is the multi homing scenarios for inter inter domain. I'm I'm thinking we may need, you know, step need need to be the into details that what kind of different scenarios for people to the home multi homing, for example, how do do they know the balance sheet, how to announce the routing for both direction. And can we give some categorize into the architecture to to show get some sense to what what we can do like that. Okay.
[01:25:26] Lan Cheng: Thanks.
[01:25:28] Joel Halpern: K. We are short of time, so you need to move quickly through this last presentation, but I wanna give you the chance to do it.
[01:25:38] Lan Cheng: Okay. Thank you. Yeah. So, yeah, this is a initial version of this draft. It presents the information requirements for monitoring source address validation enforcement. Yeah. So during self enforcement, operators need need to know whether self is enabled and actively validating traffic and which sub rule or which sub table is applied, whether the traffic passes or fails with addition, and how the traffic is actually handled. And important note is that here, our addition results and the traffic handling outcome are not the same thing. Because the how how how to handle the traffic is according to the traffic handling policy configured by the operator. And by knowing the monitoring information, the operator can have a network wide to solve visibility into the whole network, and it it will help the operator to make correctness correctness assessments and also for troubleshooting or do the stage of deployment and the transition. And now we currently divide those information into three main perspectives. The first one is traffic validation and handling information. It answers what happened to the traffic. And the second one is the cell rule generation and state information. It answers which cell rules were generated and how were they derived and are they or if they were up to date. The third one is SAV configuration profile. It answers where the star is deployed, deployed on which routers, which interfaces, and what kind of policies have been configured. For for the first category, the first first important item is the validation results of traffic, whether whether a traffic whether data packets pass or fill the validation against the the subtable. The second one is the traffic handling outcome, whether traffic is being blocked or permit or or or or being limited or maybe redirected. Yep. There are many kind of actions. And the ingress interface is also very important because current the current soft table is closely as closely deployed on a specific router interface, as well the matched sub rule to help the operator to know which sub rule produced the validation results as static results. And the second second set category, the first item is the several contents. Maybe in the it it it should should the operator may need to know the prefixes in the allow list or, you know, deny list of the contents, as well as the several size, such as the number of prefixes in the sub table or the storage resource usage. It can help operators to know the resource consumption and maybe some scaling issue, as well as the information sources used for your generation and the raw update status. And for the third category, we include the SAU enable status, mix to mix help the operator help help the network operator to know which routers, which interfaces have been deployed, the cell mechanism have worked to check traffic. And the traffic handle the policy configured by the operator in each interface or maybe in each routers. As well as the configuration change history. So as we can see, this is a very initial version of this doc documents. So there are two areas for open question, open consideration. The first area is information requirements. Do we have at least, do we need to add more information categories? Do we need to add more information that may be interested met by the operator? The second area is about the monitoring mechanisms. Whether or which existing network monitoring telemetry mechanisms could provide this information. Do we need a new algorithm? Do we need the extent existing mechanism? Okay. So we welcome the operational experience and from the community. Thanks.
[01:30:40] Joel Halpern: Okay. Thank you. I don't see anybody on the queue and we are out of time for our meeting room. So thank you guys very much for your time and for your engagement. While I've had to be a little nasty on time, I really like the discussions at the microphone. I look forward to hearing from all of you on the list and hopefully seeing most of you in November in San Francisco. Thank you.