## SAVNET BoF (non-WG forming ) - IETF 113, Hybrid * Thursday March 24, 2022 * 10am - 12pm (two hours) * Room: Grand Park Hall 1 * Chairs: Joel Halpern jmh@joelhalpern.com， Job Snijders job@fastly.com * AD: Eric Vyncke evyncke@cisco.com * Note takers: Shuping Peng, YangYue --- ## Welcome & Preliminary Notes (10 min) --- ## Background & Gap Analysis (15 min+20 minutes) Find draft here: [link](https://datatracker.ietf.org/doc/draft-li-opsec-sav-gap-analysis/) Dan Li Presents. Ted Lemon: (on slide 8) In this model you trust the routers. The AS1 routers and the AS2 routers basically enforce the address validation. Is that correct? Dan Li: Yes. Ted Lemon: So in other words, what you're stating here is that if cost a if a device on the customer network, sends a packet to the AS1 router, the AS1 router that's got a bogus source out, the as one router is trust worthy, you trust the AS1 router to block that packet,is that right? Dan Li: You mean the blocking behavior is AS4 right? We still focus on the blocking behavior as AS4 right? Ted Lemon: The problem you were describing here is that it's possible for someone in as one or as two to spoof packets from AS3, right? Dan Li: Yes, maybe this case is exactly that AS4 cannot distinguish AS1 and AS2 to spoof the address of each other, AS3 is AS1 and AS2's customer.If AS1 and AS2 deploy the same mechanism, maybe this kind of spoofing can be detected and avoided.then AS4 can differentiate the case, and trace back the spoofing. Ted Lemon: Right. The problem I'm asking about here is I am trying to understand the trust model. You're assuming that the routers are trustworthy, AS1 is going to reject the bogus source address from its own internal network and that's part of the trust model. Is that right? Dan Li: Actually, it's like this because either uRPF or this kind of save mechanism,they just make the source address base on the incoming port.for the incoming port they can only judge the correct direction of this source address. But if there is some smoothing between the ASes along the same path,actually, they can not distinguish between them.But the key is that if we can do this, it can offer packet direction checking.Even though there there is some source address booming on the pass, we can skip and help us trace back source transposing. Ted Lemon:YYour solution sounds like complex and wonderful,but it still have the trust problem.so saying why that model actually makes things better is important. I just wanted to ask about the trust model because I think it's really important. Dan Li: Trust model in the DSAV is the same as that in uRPF. After this kind of trust model is also the trust model used in urpf. What is kind of incoming port with the safe mechanisms have this same trust model. Maybe we can just make it more clear. Bao Tao: I saw you analyzed the improper permit problem of EFP-uRPF in the inter-domain case, and mentioned Algorithm A and B, what is the difference? Lancheng Qin: Actually, these two algorithms were proposed in of the rfc 8704.The difference is that the algorithm A applies individual alowlist list at each customer port based on the rules received by that port. It may have improper block problem. When one customer port does not receive in the route for the AS, just like the scenario in this case. For algorithm B, it applies the same analysis to all the customer ports. It will also allow the packet with source addresses of all the customer Ases. Algorithm B can solve the improper block problem but has the improper permit problem if they come from the customer interfaces. This is algorithm B. By algorithm B, it can avoid the improper block problem in algorithm a, but may have improper permit problem. Because this is because ASes in the customer cone can spoof each other. If you have more interest, I think you can refer to the rfh 8704. It has a very detailed description. Giuseppe Fioccola: The presentation analyzes the improper behavior of uRPF and finds that the root cause comes from the local FIB/RIB of routers. It is suggested the real data-plane path discovery as the solution but we need to pay a cost for this. How about using multiple feasible paths to apply SAV rules? Can it work? Dan Li: Jari has the similar quesiton. Alternative way is to use some feasible path. It has both the improper block and improper permit problem. Tim Donne: I have a question for the individual main case. You only mentioned several rules in the customer ports, but not mention the provider and peer ports. Can you explain the case? Dan Li: Some improvements on Customer ports. But the carriers ports and Peering ports use uPRF. x: Something describe that network topology or something. Then I have a compliment on that, which it's been historically incredibly hard to get not only customers for is ps to publish. Who their customers are, what other space that they use or want to be used. And that has that has been an incredibly hard operational task. Dan Li: For this network-level notification protocol. Maybe there is some sacrifice on the privacy issue. It's business relationship because it will just explicitly send out the notification message. So this message may lead to some private privacy issue. But with generality, we think that it is a trade off between privacy and security. Design more mechanisms to limit the impact. Jari Arkko: If there is not enough information, then you need more information. If you have a feasible routes, then you have to decide what you want. Dan Li: Actually, we have already discussed some of your question in the mailing list. For todays Internet, try to reduce the overhead. During the convergence period. We have to pay for the packet drop. If there is a loop, then there will be a packet drop. It is similar. We have designed in several ways. Very interesting debates. We could debate more in the mailing list. Igor Lubashev: The reason we have this problem is that we use BGP. What do you think the acceptable cost for the solution? Dan Li: This issue will be described in more details in the next version. We should divide the protocols into intra- and inter- domain. For the intra-domain since it is smailler, so we can design new protocol. The cost should not be higher than the routing protocol. That is the general thinking for the cost we need to pay. The SAV protocol and the routing protocol are two parts. Maybe we can just exchange the capabilities of bgp to help curry or get more information required for this. Maybe we can just exchange the capabilities of bgp to help carry or get more information required for this Weiqiang Cheng: The backbone network is large, maybe reach 1,000 routers. I guess it's reasonable that put the being suitable for the large scale, we design the network with network-level protocol. --- ## DSAV Framework (15 min+20 min) Find draft here: [link](https://datatracker.ietf.org/doc/draft-li-dsav-framework/) Lancheng Qin presents. Nalini Elkins: I believe it depends on a hop by hop, header and being accurate and not spoof. If they're hot by half extension, header is bad to start with what there you go. We are happy to work with you on that because we have an idea ourselves, because we have another ipv six extension header that we need to be extremely accurate. So if you want, we can explore collaboration. But let me see what you think about that? Dan Li: we are glad to explore collaboration. Ties：It may be a method for doing that. But in fact, you can spread the message to all the neighbors. So you can discover all possible paths. Dan Li: Just want to minimize the a number of protocol messages during this whole process of perfect solidification.We use the RIB for the notification because what we want to a discovers a real data forward in path. Linda Dunbar: You consider using the ACL as well. The validate source address, destination address, and also the port number. Do you have an analysis like showing different ways incorporated with ACL? Lancheng Qin：Yes, we can use the control-plane routing information to find policy-based forwarding path, including ACL redirection and some tunnel technologies. Linda: How to deal with tunnel? where to do validation? Lancheng Qin: Validate at the ingress node. Huaimo Chen: If you use IGP,there are periodical update. Lancheng Qin: I think IGP cannot learn the real forwarding path. Many factors affect forwarding rules. Static routing and ACL redirection can affect the forwarding path but other routers cannot learn this information through IGP. Huaimo Chen: If you use BGP, you don't need to update,right? Lancheng Qin: Maybe we can use BGP to do the prefix notification. Whether designing a new protocol or extending existing protocols is an open question. Mengxiao Chen：A question in your analysis of scalability of DSDS. You think that's in most cases, a node with you only one propagation message originated from every other node. Could you explain why? Lancheng Qin: Node 1 Node 1 only sends one message to each next hop. And during the process of prefix notification, eeEach node only receives one message. They can generate accurate SAV rules. --- ## ESAV Framework (10 min+10 min) Find draft here: [link](https://datatracker.ietf.org/doc/draft-xu-psav/) Yangfei Guo Presents. Nalini Elkins:Can you explain more what this verification of tag entails? Haiyang Wang: Our responsibility is to design a protocol that is wrong in in the day cares to validate the identity of those kids.Basically what we do is that, first of all, we don't search actually the actual routing table up there.We actually only need to check the destination of prefix,and check if this destination is resumed they care or outside with it.If it was in the take care, we send it to our interdependent protocol if it's outside, then we give this kid a sticker.And then we send this kid out.This is not going to hurt the sender of the packet or the receiver of the packet. It is only going to hurt those evil autonomous systems who refuse to check the tech. If that makes sense to you, the thing is that our deployment, we don't require all the day care to check those stickers. Yuanxiang Qiu: label a package, whether this additional overhead, we'll have a significant impact on the efficiency of interdependence. It transfers. Thank you Haiyang Wang: We actually deployed that in a virtual router to environment that is relatively a large scale virtual network. we actually deployed that in a virtual router to environment that is relatively a large scale virtual network.And talking about latency, we don't have very detailed data out there. But the preliminary test showing that the issue it is going to add in approximately ten Michael's seconds, late delay. She would have packet processing. Benjamin Schwartz: MTU overhead? Haiyang Wang: We're not going to actually add extra header or extra information on top of the actual version six header. Benjamin Schwartz:Where does it go in the header? Haiyang Wang: The existing implementation is that we put that in the destination option. how long is that tag? Haiyang Wang:It's like 64. I guess, 64 bytes. It's 64 exists. So it's like an eight. Benjamin Schwartz: (comment) A disaggreement. I really think that we should consider static set up instead of trying to do dynamic arrangements between the ASes, which creates kind of an N-squared problem. --- ## Open Discussion (20 min) Jared Mauch: I think that there's the opportunity for there to be some interesting work in the space describing. But I think it also is going to pose some real challenges when it comes to actually deployment, which is basically see everyone who's tried to either do route filtering or BGP path scale. Zhenbin Li: I think that's is a great, there's the draw back of the existing the source address validation solutions, such as uRPF. It is a truly worse to explore the possible solutions to this issues. But I think that concern is the possible of the cost. Maybe we need to go on to discuss this possible solutions for this .Thank you. Eric: I am the responsibility for this BOF and I would love to thank the chairs and the speaker for the clear presentation.Now, we got the solutions in problem space has been presented. We were presented with two solutions. I wonder whether they are. There is a third and a fourth potential solution to this. The problem really needs to be explored. There was a mailing list certainly of the talk. I'm really quoted conversation continues there. Yan Gao: We believe that the problems raised by DSAV are valid and important. We are also doing tracking of related technologies. Compared with the previous technologies, decisive provides, some more generous solutions is worthy of more efforts. We think it's necessary to promote the standard, the vision of deceiving it. At the same time, we intend to carry out standard promotion in China communication standards association. ## Chat Log ``` IETF SAVNET savnet@jabber.ietf.org Thursday, March 24, 2022< ^ > Room Configuration Room Occupants GMT+0 [08:45:08] ~~dhruv~~dhody~~ has set the subject to: IETF 113 SAVNET-BOF [08:49:06] I am getting the same error. [08:49:07] We're aware, working on it [08:49:16] <Éric Vyncke_web_470> Same inroom [08:49:30] Yes, the in room screens pull the slides from the same source [08:50:39] <Éric Vyncke_web_470> I see the slides on my laptop but not on the room big screens [08:52:21] thank you meetecho! [08:52:31] <Éric Vyncke_web_470> (it seems that most WG have the same issue, slightly comforting that savnet is not the only one ;-) ) [08:53:19] <Éric Vyncke_web_470> Joel & Dan, can you try to say something ? (radio check) [08:53:41] I said something. Can you hear me? [08:53:52] I have no audio [08:53:59] My screen shows "unable to attach media" [08:54:02] We're aware, working on it [08:54:06] no voice [08:54:21] i was talking into the mic, i guess you didnt hear me [08:54:30] we will wait until the system works before starting the session [08:54:37] Yes we cannot hear your, job [08:54:47] I must scream and I have no audio. :satisfied: [08:54:49] ok! no worries, i'm sure it'll work soon [08:55:09] We're restarting the room, you may be kicked out temporarily [08:57:58] <Éric Vyncke_web_214> seem better [08:58:18] yaya&Alice_web_368 joins the room [08:58:20] <~~dhruv~~dhody~~> wooo hooo! [08:58:26] Can you confirm it's ok now? [08:58:31] <~~dhruv~~dhody~~> yes [08:58:48] yaya&Alice_web_368 leaves the room [08:58:49] They got it fixed before starting time. All good. [09:22:28] SAV table is effectively superset of FIB. [09:23:52] yeah, adding more asymmetric source prefix info [09:26:21] Thanks to whomever adjusted the mic hight. Folks in room need to be very close to the microphone. [09:26:50] Thank Jared :) [09:26:59] does anyone have an empty sheet of paper for me? [09:29:42] @ted I think what you're trying to discuss is covered by what the underlying existing u-rpf features are intended to accomplish? [09:31:52] <Éric Vyncke_web_214> https://datatracker.ietf.org/doc/html/rfc8704 [09:34:26] Mengxiao, please wait until we call on you. [09:34:52] The core observation you can derive from RFC 8704 is that if you use the BGP information to figure out what prefixes are originated by a given AS, you can use that to help fill in gaps when you have partial routes on a given session. [09:35:11] Giuseppe is a bit quiet in the room. Could someone type his comment here? [09:35:36] joel - did you catch it? [09:36:55] from my understanding, current uRPF-based tools more focus on access and northbound protection, not so good for east-west bound and southbound [09:37:52] which is very import for one ISP perspective [09:38:00] @Tim - it seems someone jumped in front of you! Please hold, you'll be next [09:42:21] we are cutting the queue after Jeff Haas! [09:42:35] to move on to the protocol proposals [09:42:45] +1 with Jared: especially for Tiers-1 who have a large customers cone ... [09:44:27] I'll save my comments for the proposal space. [09:44:52] ok [09:45:00] My question was: The presentation analyzes the improper behavior of uRPF and find that the root cause comes from the local FIB/RIB of routers. It is suggested the real data-plane path discovery as the solution but we need to pay a cost for this. How about using multiple feasible paths to apply SAV rules? Can it work? [09:45:16] Tony Przygienda_web_410 joins the room [09:45:33] It can help, but it cannot fix all problems. [09:45:46] yaya&Alice_web_398 joins the room [09:45:52] Partial answer to Jared's observation is that local router knowledge is incomplete for a given AS in BGP. If you can get global routing knowledge within the AS, you can augment local router knowledge. That's most of rfc 8704. [09:46:10] Past that point, you have to decide what you don't know and then add it to the set of info. [09:46:30] Higher level question: are we solving the right problem? We seem to have jumped into the very hard problem of transitive verification. [09:46:39] ^ [09:46:46] @Tony L: +1 [09:46:57] BCP 38 tried (and failed) to solve the very simple question of local verification. [09:47:14] Fixing that seems to be 99.999% of the problem. [09:47:22] For edge networks, bcp38 can do a very good job. [09:47:28] yepp, once we start to talk path validation instead of origin validation we are pretty soon in BGPSEC territory anyway [09:48:01] rfc 8704 indirectly says you can use RPKI ROAs to seed your augmented state. :-) [09:48:02] Dan Li replies to me that does not completely solve the problem. It is similar to feasible uRPF. [09:48:05] We didn't get BCP 38 deployed. How do we things differently so that eyeball networks enable it? [09:48:27] <Éric Vyncke_web_214> The incentive is indeed a key Q [09:48:55] The incentive is easy: when you have networks that are known to not implement bcp 38, you drop their packets. [09:48:55] <Éric Vyncke_web_214> meetcho: we lost slides [09:49:14] Checking [09:49:19] <Éric Vyncke_web_214> problem sovled [09:49:30] Ack [09:49:34] yeah, we have to pay some cost to cover the limitation casused by local intelligence [09:49:58] @Jeffrey: hope this is a joke ... [09:50:14] A very grim one, @jean-michel. [09:50:33] If your security model needs to not deal with spoofing, you lock things down. [09:50:59] if your security model isn't strict (usual general Internet case), you decide what you do about incomplete filtering [09:52:11] remember this methodology is not strictly about general ISP case for end users - it applies to stricter security scenarios as well. [09:52:39] @Jeffrey: "be conservative in what you send, be liberal in what you accept" ... something you forgot? :) [09:53:02] @jean-michel: "My network, my rules". [09:53:40] @Jeffrey: '"my network, my business" I would say* [09:53:41] @Jean: this works well if you deal with a system where most actors are benign, arguably what Internet is being populated with/is used for shifted very dramatically in last 10+ years. Otherwise we wouldn't have this kind of workgroups ;-) [09:53:55] ^ [09:54:31] [09:54:46] Insert Tony's regular chant. [09:55:02] Monika Ermert_web_210 joins the room [09:55:10] The main issue regarding uRPF is that network operators are afraid to drop legitimate traffic [09:55:23] and uRPF is a black box [09:55:31] A valid concern for general purpose cases. [09:55:32] and the original quote was arguably about control plane where generally I don't talk to folks far away and I tend to trust them otherwise I would't set up a peering to them (and in IGP it's 99.999% my own router on my own link and I assume I'm not schizophrenic so I trust myself). Data plane transiting stuff is a different ball game ;-) [09:55:41] Avoiding dropping legitimate packets is goodness [09:55:42] <Éric Vyncke_web_214> Or some operators are lazy / do not care or even are hostile ? [09:57:06] There are several cases of that. [09:57:11] to earlier comments, Eric, bcp 38 implemented pervasively at the edges solves most of the real things people are concerned about for spoofing. In the absence of it, you're passing the tax to try to do something almost as good further into the network. [09:57:25] and transitively, the closer you get to the internet core the harder it is to do it right [09:57:39] Shuai Zhang_web_206 joins the room [09:57:40] So why not fix the problem at the leaves? [09:58:00] @Tony: that was the goal with SAVI [09:58:11] as you said tony, it hasn't gotten deployed. so, people are trying to push the solution outward. hence this bof [09:58:29] So we've given up? Sad. [09:58:45] @Tony: but we could meet the same "fear" (i.e., drop of legitimate) traffic [09:59:04] @tony, we need all leaves behaving well, but this is impossible :( [09:59:12] Why not? [10:00:41] numbers of the leaves are huge [10:00:58] +1 we really have no choice, state in the core is just very, very expensive and aggregated. only way internet works really. and if we avoid the state and do some "validation by proxy" at the speeds data plane is going in the core it's a fool's errand [10:01:01] So? If everyone filters their own network, it's easy. [10:01:09] <Éric Vyncke_web_214> and would you blindly trust all leaves ? [10:01:14] No [10:01:38] Trust, but verify. And when that fails, what can we do? [10:01:52] <Éric Vyncke_web_214> Better than nothing.... I agree [10:02:10] Tony P. is correct. Once you're in the core, the possible source paths become extremely large. [10:02:46] Filtering at traditional tier 1 ISPs is impractical. At tier 2, probably impractical. tier 3... possible. [10:03:01] observe that we already do a "reverse BCP" today. your home router has oodles of filters and automatic blocking if some "friend" tries too many times and fails on port 22 ;-) [10:03:25] Yes, but that filter is on the wrong side of my downlink. [10:03:40] which I agree with ;-) But desperate times breed desperate measures ;-) [10:04:04] I can live in a country with low crime rate or I can invest in crating my windows up ;-) [10:06:12] Please don't talk over the speaker. [10:06:17] joel, you have open mic [10:06:19] the fact that there are significantly less countries with low crime rates than ones with windows secured is an interesting etymological observation here. We started with Inernet as Utopia which it was for a bit but Utopias tend to becomes Lord of the Flies mostly if not put under governance and then making sure that participants have a strong stake in low crime rate. Or we could go to ML and build "Minority Report". The last thing is a joke of course ;-) [10:06:20] <Éric Vyncke_web_214> Joel we hear you... [10:06:27] Joel I muted you [10:06:32] Oops. Sorry. Thanks Job. [10:08:27] @Jeffrey, cone-based partial deployment might be pratical for first step [10:09:21] @mingqing incremental deployment makes the network incrementally better for those participating. [10:09:49] My grim observations and tony P's observations is what happens when you have a network with both those who try to behave well and those who don't behave well. [10:10:00] Really novice question / sanity check: The project here is to figure out how to do this filtering without crushing the core of the network with compute or state? I ask because this doesn't seem like the simplest way to do this. [10:10:23] @pete - dsav or this problem space in general? [10:10:33] General. [10:10:36] randomly musing: why does this look like PIM uRPF ;-) [10:10:41] <Éric Vyncke_web_214> It seems simple but the amount of states and messages is huge [10:10:45] because it doesn tony. [10:10:54] Re: leaves discussion. One of the challenges is of course that you can improve your own address validation, and you can even get your friends to improve theirs, e.g., by adding some of the tools suggested in this BOF. But, you and your friends were the ones who were already doing end-customer address validation on all links anyway, so we improved ... not much. And as long as you still need to peer with the sloppy guy you are still susceptible to address spoofing from them. That being said, if we had a better-than-EFP-uRPF at a reasonable cost, it would be a reasonable RFC to make. [10:10:55] u-rpf is 'easy'. it was a hack. [10:11:14] @jari "tragedy of the commons" [10:13:40] dsav looks like multicast but there are some differences. Multipath maybe one of them. [10:13:49] @Éric: I was wondering about the number of states in DSAV. I guess I didn't understand that the number of messages counts as "huge" in this space. Interesting. [10:14:05] @Jari: this is the goal of the MANRS initiative (i.e., to build a community of ISPs willing to improve Internet security) [10:14:26] chenmeiling_web_826 leaves the room [10:14:27] The presentation isn't really accounting for routing churn as an input at this point. [10:15:38] Tony P. would probably consider this to be the same as pim tree churn. [10:16:25] @Jari Agree d. Improving accuracy with bearable cost. [10:16:36] to give the discussion another angle that most are probably not familair with. The very underlying cause of this malaise is that Internet has no "cost function" as other network technologies had (mostly). i.e. when I charge you seriously for the stuff I have to carry for you you may think twice about giving me useless crap. So in a sense peering pricing based on usefullness of traffic helps but you'd need to charge the source/destination reliably based on the value of stuff the network decides to carry. I oversimplify drastically but thinking through Hayek's "invisible hand" often fixes problems that are intractable otherwise (it's going toward's Nash's PoA BTW). We are techies, we often build technology to try to prop up a system with fundamantelly bad policies in place. [10:17:12] It's one step worse, Tony P. If you charge by the bit, attack traffic is profit. :-) [10:17:25] yeah, this is 100% PIM churn before learning first scaling lessons (periodic RIP readvert are fun but only for very short time ;-) [10:17:39] @Jeff: yes, that's where we are today [10:17:50] The volume and dynamics were I believe on their open quesitons list. [10:18:09] @Jeffrey: that's always been my problem with otherwise good security technologies like BGPSEC -- the middle layers really don't have incentive to deploy technologies that reduce their profits by dropping traffic. [10:19:16] @Joel: thanks. yeah, I'm sorry, I'm not up to date on this BoF, I'm only here because other sessions were cut short but in fact, this a very interesting BoF here ;-) [10:19:26] <Éric Vyncke_web_214> It is not the IPv6 extension header hop-by-hop [10:20:12] Feng Yang_web_381 joins the room [10:20:25] <Éric Vyncke_web_214> BoF are always the most interesting sessions IMHO (at least for me) [10:21:09] @Tony P. thanks for joining, and raising perspectives. [10:22:10] Question 6: I am a "leazy ISP" (c)Erik ;) not willing to filter spoofed IP addresses and I send a DSAV message allowing all IP packets ... how to solve this problem? [10:23:01] about incentive for one isp, i guess is that one will be able block spoofing traffic coming in self zone [10:23:27] @Jean-Michel I think that is a question for the next presentation. This one is intra-domain. [10:23:55] not only just for outgoing traffic [10:24:30] Nicola Rustignoli_web_342 leaves the room [10:24:51] @Joel: good point - I missed this was related to intra-domain, sorry [10:25:18] <Éric Vyncke_web_214> @Alexandre, the 'propagation scope' (naming is confusing) appears to me required as packets src prefix can have different path based on their dst. So, the paths are really bound to src/dst prefixes [10:27:05] the mechnism of DSAV, i think, works for intra- and inter-domain [10:27:08] @Jean-Michel The question is valid. And apparently they are now also including inter-domain. COnfuses this co-chair. Sorry. [10:28:05] you could build something that back-pressures saying "yuo're giving me crap I'm being pushed back on and not paid". Whichever way you cut it, you need a credentials system you can build a pricing model on and conduct economic transactions cheaply and reliably. and of course juristicion to arbitrate. So, in a sense a society rather than "wild west" that we have today. You could have interesting ideas like .e.g MX has white/gray/blacklists you can vote on. And BTW, look @ MX, it's almost fully secure now after the reputation system started to kill peple's resolution of mail servers. E'body has a cert and behaves pretty decently. Spam email is way way down which is probably to a good extent due to that. Yeah, servers are still broken into, there are shady players like junk mail replicators (but their ISPs charge them juicily for that AFAIU). So that's one way of thinking about making ISPs behave and see what they take on ... [10:28:18] Timothy Carlin_web_133 leaves the room [10:28:56] as someone who operates a mailserver still, tony, I think you're a bit off. :-) [10:29:24] so do I and good luck trying to send/receive stuff if you don't have a good cert ... [10:29:41] <Éric Vyncke_web_214> esp to gmail.com indeed [10:29:54] yeah, gmail.com is its own story ;-) [10:30:07] I don't get the trust model. If I trust these notifications, why don't I trust these networks to just do their own filtering? [10:30:17] <Éric Vyncke_web_214> ;-) [10:30:42] or s/networks/routers/ for intra-domain [10:30:47] Yuexia Fu_web_179 leaves the room [10:30:47] the cost of getting an anon account on leggit cert server is way too low. That's economics question one layer up ... Those puppies do not sell services, they give you free lunch to get your data as free lunch ... [10:30:51] Yuexia Fu_web_448 joins the room [10:30:58] <Éric Vyncke_web_214> I guess it is more to be sure that packet drop at the edge can be done [10:31:22] @Ben I think that is one of the key questions that needs to be explored. [10:31:54] Unfortunately, we are out of discussion time. I hope we have a little more at the end. [10:34:00] i cannot hear the presenter [10:34:44] Checking [10:34:44] We will switch to a new presenter [10:34:57] ok [10:35:06] @Ben: I think that as soon as you trust a router you are open to attacks. Messages need to be authenticated and validated. [10:35:06] the third presenter has some network problem [10:35:30] Haojie Wang_web_582 leaves the room [10:35:32] Luigi: Agreed, hence why I am more interested in end-to-end validation [10:35:56] audio is good! thanks [10:35:59] <3 meetecho [10:37:40] @Ben: meaning BCP 38 like approach? [10:38:11] Luigi: I'm hoping for something like ESAV! [10:38:21] think what if an attacker can break into the relay of messages? so I guess the assumption is the between router communication is safe [10:40:43] @Ben: the advantage I see for DSAV is that it may be more effective against DDoS. ESAV may be a victim of DDoS. [10:40:43] Dirk Hugo_web_920 joins the room [10:41:14] Yingzhen, the security model is effectively the same as that of BGP itself, and definitely the security of any central controller driven network. [10:41:18] I think the dynamic setup for ESAV seems like a major weakness. I would prefer static config. [10:41:31] (^Luigi) [10:42:06] @Jeff, agreed. same BGPsec story [10:42:14] I think looking at RPKI as a foundational framework for distribution of crypto thingies is a good approach [10:42:45] Not quite bgpsec. a bit like aspa [10:42:59] jared called it "ASPA for packets" [10:43:33] :) [10:43:54] Crypto in the data plane seems like a non-starter. [10:44:15] Effectively, one way to state where rpf filtering can be helpful is whether or not is "can I build a simple path graph to a given origin" [10:44:46] Tony: Why? It can easily run at line rate. [10:44:53] presuming you can build the graph, there's enough data between the routing system and things like RPKI that you can build the filter graph in a mostly dynamic and partially augmented graph [10:44:53] if it can do that it has to kill aggregation AFAIS which for core is a non starter [10:45:29] The current presentation looks like a 4th label data plane (in addition to MPLS, SRv6, and LISP) [10:45:37] I am with Benjamin on this [10:45:46] @Ben: Pointers to routers with line rate at 800Gbps on all ports, please. [10:46:22] you can do anything at line rate depending a) what your line rate is b) how much power you can push into a chassis and more importantly cool it again and c) how much money you have ... I doubt you'll be willing to pay 5x your internet access rate or run at 1/5 the speed at current price [10:46:27] rpf on all router architectures I'm familiar with take a line rate hit due to additional lookup for the rpf. [10:46:30] @Eduard V - not sure I follow you. This information is not directing forwarding. It is confirming source information validity. [10:47:03] the name of the presentation "data plane approach" then "tag" [10:47:04] all techs we're discussing to augment the lookups for a "sav table" will consume fib resources, which are usually considered precious and have scale impact. [10:47:08] And crypto will be more expensive than RPF. [10:47:12] rpf hit is relatively bearable but yeah, those pesky photons and electrons insisting on laws of physics ;-) [10:47:47] @Eduard: looks like RFC3514+crypto [10:47:47] I suspect clever asic implementors can give us the double lookup (fwd + rpf) as a feature... but that's not how it's built right now. [10:48:19] Parallelism should work. [10:48:20] ;-) yes, but you pay for speed with gates then ... [10:48:29] TANSTAAFL [10:48:53] Always [10:49:06] that comment only applies in capitalist systems! ;-) [10:49:09] Weiqiang Cheng_web_426 leaves the room [10:49:28] @Jean-Michel Combes: RFC 3514 is 1st of April [10:49:30] In non-capitalist systems, there is no lunch. :) [10:49:36] Anarcho-collective forwarding engines have a longer consensus model [10:49:45] @Eduard: I know :) [10:49:56] the immortal quip of Churchill "capitalism is the worst system, except all the other ones we tried" [10:50:11] @Edouard: but the idea is more or less the same I would say [10:50:17] *Eduard [10:51:41] @Jean-Michel Combes: thanks. I need to read [10:52:41] By analogy, esav appears to be SFC carried out among cooperating ASes where the service function is validation [10:52:58] <Éric Vyncke_web_214> Good summary [10:53:44] Deep crypto isn't super helpful in many respects. You need enough sprinkled in there to not worry about external spoofing of it through routers that aren't protected. [10:53:46] agreed. good analogy ... [10:53:52] An this may scale better than a H-by-H approach [10:54:37] Tagging is not a bad idea; it can help. But it still means solve the prior problem better: you need a correct rpf graph. [10:55:00] <Éric Vyncke_web_214> @Luigi it seems so, also easier for incremental deployment but tagging all packets... [10:55:11] agreed. on rpf, yes and no. what if you tag stuff up based on credential of the ISP passing you stuff if it's not tag'ed already [10:55:14] Jiao Kang_web_956 leaves the room [10:55:20] This is also the "throw stuff away" bit that I had mentioned to @jean-michel earlier. [10:55:33] tags could scale and you could re-tag as well. It's basically MPLS in another flavor and that is fast enough we know [10:55:47] <Éric Vyncke_web_214> inserting header is a NO GO [10:56:16] if the trust model is cooperative then you don't need to stack tags, just replace with a "trusted by union of parties" tag [10:56:19] @Eric: agreed. Incremental deployability is key. [10:56:30] yeeah, throwing in a header as we know, except few people who think it's best place to do routing ;-) is a very expensive proposition [10:56:32] <Éric Vyncke_web_214> draft-vyncke-v6ops-james (sorry for the ads) to hceck whether ext header travels the global Internet [10:57:13] I'll also refer people to the IEPG presentation this week where it was shown that certain types of ipv6 headers just guarantee your traffic is dropped. [10:57:23] ;-) [10:57:29] Gorry Fairhurst_web_491 joins the room [10:57:35] dropped for your own good BTW ;-) [10:57:43] I blame Ron Bonica. [10:57:43] If we're going to do that, let's just put the full path in the header. We can call it 6vRS. [10:58:07] <Éric Vyncke_web_214> What about IPv10 ? [10:58:16] @jeffrey, which presentation are you referring to ? [10:58:45] Eric: Has that come up yet this IETF? [10:59:01] IEPG: https://www.youtube.com/watch?v=u2wVZnJ3fo0 [10:59:08] Ha [10:59:15] Sorry, slides don't look like they're available. [10:59:17] <Éric Vyncke_web_214> BTW, please join savnet@ietf.org [10:59:18] @antoine - as usual, chairs haven't gotten their materials posted, so I don't have the easy referral. :-) [10:59:35] They usually catch up in 2 weeks to 6 months. [10:59:41] best to unicast them. [10:59:56] Thanks for the pointers ! [11:00:03] :-) IEPG is delay tolerant [11:00:10] Will do :-) [11:00:48] IEPG meeting: https://www.potaroo.net/iepg/2022-03-20-ietf113/index.html [11:02:46] thanks Jean [11:03:26] Thanks [11:03:28] I think this is interesting topic, worth exploring [11:03:33] Ole Trøan_web_407 leaves the room [11:03:56] It is difficult to decide what to do here, for me at least. There are a number of options. I for one would be interested in some improvements, but maybe more on the "minimal" side (e.g., what Igor suggested) rather than creating large complex new infrastructure, which I fear would not be deployed widely enough in the end. [11:04:19] <Éric Vyncke_web_214> Correct, shared opinion Jari [11:04:28] Nicola Rustignoli_web_304 joins the room [11:04:33] Eduard V_web_557 leaves the room [11:04:35] I think we should aim for something that carries significan benefit at low deployment [11:04:57] IMHO, this seems like a waste of time. [11:05:01] End-to-end systems often have this property, since they do not rely on any intermediary routers to do anything [11:05:10] <Éric Vyncke_web_214> Thank you all [11:05:12] Thank you everyone [11:05:32] Thanks ```