Find draft here: link
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.
Find draft here: link
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.
Find draft here: link
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.
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.
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] <Joel Halpern_web_764> I am getting the same error.
[08:49:07] <Meetecho> We're aware, working on it
[08:49:16] <Éric Vyncke_web_470> Same inroom
[08:49:30] <Meetecho> 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] <Job Snijders_web_662> 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] <Dan Li_web_871> I said something. Can you hear me?
[08:53:52] <Tony Li_web_946> I have no audio
[08:53:59] <Dan Li_web_871> My screen shows "unable to attach media"
[08:54:02] <Meetecho> We're aware, working on it
[08:54:06] <Long Luo_web_212> no voice
[08:54:21] <Job Snijders_web_837> i was talking into the mic, i guess you didnt hear me
[08:54:30] <Job Snijders_web_837> we will wait until the system works before starting the session
[08:54:37] <Dan Li_web_871> Yes we cannot hear your, job
[08:54:47] <Tony Li_web_946> I must scream and I have no audio. :satisfied:
[08:54:49] <Job Snijders_web_837> ok! no worries, i'm sure it'll work soon
[08:55:09] <Meetecho> 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] <Meetecho> 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] <Joel Halpern_web_532> They got it fixed before starting time. All good.
[09:22:28] <Jeffrey Haas_web_230> SAV table is effectively superset of FIB.
[09:23:52] <Mingqing Huang_web_640> yeah, adding more asymmetric source prefix info
[09:26:21] <Joel Halpern_web_532> Thanks to whomever adjusted the mic hight. Folks in room need to be very close to the microphone.
[09:26:50] <Job Snijders_web_262> Thank Jared :)
[09:26:59] <Job Snijders_web_262> does anyone have an empty sheet of paper for me?
[09:29:42] <Jeffrey Haas_web_230> @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] <Joel Halpern_web_532> Mengxiao, please wait until we call on you.
[09:34:52] <Jeffrey Haas_web_230> 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] <Pete Resnick_web_576> Giuseppe is a bit quiet in the room. Could someone type his comment here?
[09:35:36] <Job Snijders_web_262> joel - did you catch it?
[09:36:55] <Mingqing Huang_web_640> 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] <Mingqing Huang_web_640> which is very import for one ISP perspective
[09:38:00] <Job Snijders_web_262> @Tim - it seems someone jumped in front of you! Please hold, you'll be next
[09:42:21] <Job Snijders_web_262> we are cutting the queue after Jeff Haas!
[09:42:35] <Job Snijders_web_262> to move on to the protocol proposals
[09:42:45] <Jean-Michel Combes_web_233> +1 with Jared: especially for Tiers-1 who have a large customers cone ...
[09:44:27] <Jeffrey Haas_web_230> I'll save my comments for the proposal space.
[09:44:52] <Job Snijders_web_262> ok
[09:45:00] <Giuseppe Fioccola_web_662> 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] <Tony Li_web_233> It can help, but it cannot fix all problems.
[09:45:46] yaya&Alice_web_398 joins the room
[09:45:52] <Jeffrey Haas_web_230> 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] <Jeffrey Haas_web_230> Past that point, you have to decide what you don't know and then add it to the set of info.
[09:46:30] <Tony Li_web_233> 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] <Jeffrey Haas_web_230> ^
[09:46:46] <Tony Przygienda_web_410> @Tony L: +1
[09:46:57] <Tony Li_web_233> BCP 38 tried (and failed) to solve the very simple question of local verification.
[09:47:14] <Tony Li_web_233> Fixing that seems to be 99.999% of the problem.
[09:47:22] <Jeffrey Haas_web_230> For edge networks, bcp38 can do a very good job.
[09:47:28] <Tony Przygienda_web_410> yepp, once we start to talk path validation instead of origin validation we are pretty soon in BGPSEC territory anyway
[09:48:01] <Jeffrey Haas_web_230> rfc 8704 indirectly says you can use RPKI ROAs to seed your augmented state. :-)
[09:48:02] <Giuseppe Fioccola_web_662> Dan Li replies to me that does not completely solve the problem. It is similar to feasible uRPF.
[09:48:05] <Tony Li_web_233> 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] <Jeffrey Haas_web_230> 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] <Meetecho> Checking
[09:49:19] <Éric Vyncke_web_214> problem sovled
[09:49:30] <Meetecho> Ack
[09:49:34] <Mingqing Huang_web_640> yeah, we have to pay some cost to cover the limitation casused by local intelligence
[09:49:58] <Jean-Michel Combes_web_233> @Jeffrey: hope this is a joke ...
[09:50:14] <Jeffrey Haas_web_230> A very grim one, @jean-michel.
[09:50:33] <Jeffrey Haas_web_230> If your security model needs to not deal with spoofing, you lock things down.
[09:50:59] <Jeffrey Haas_web_230> if your security model isn't strict (usual general Internet case), you decide what you do about incomplete filtering
[09:52:11] <Jeffrey Haas_web_230> remember this methodology is not strictly about general ISP case for end users - it applies to stricter security scenarios as well.
[09:52:39] <Jean-Michel Combes_web_233> @Jeffrey: "be conservative in what you send, be liberal in what you accept" ... something you forgot? :)
[09:53:02] <Jeffrey Haas_web_230> @jean-michel: "My network, my rules".
[09:53:40] <Jean-Michel Combes_web_233> @Jeffrey: '"my network, my business" I would say*
[09:53:41] <Tony Przygienda_web_410> @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] <Jeffrey Haas_web_230> ^
[09:54:31] <Tony Li_web_233> <Insert Tony's regular chant>
[09:54:46] <Tony Li_web_233> Insert Tony's regular chant.
[09:55:02] Monika Ermert_web_210 joins the room
[09:55:10] <Jean-Michel Combes_web_233> The main issue regarding uRPF is that network operators are afraid to drop legitimate traffic
[09:55:23] <Jean-Michel Combes_web_233> and uRPF is a black box
[09:55:31] <Jeffrey Haas_web_230> A valid concern for general purpose cases.
[09:55:32] <Tony Przygienda_web_410> 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] <Jari Arkko_web_743> 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] <Tony Li_web_233> There are several cases of that.
[09:57:11] <Jeffrey Haas_web_230> 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] <Jeffrey Haas_web_230> 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] <Tony Li_web_233> So why not fix the problem at the leaves?
[09:58:00] <Jean-Michel Combes_web_233> @Tony: that was the goal with SAVI
[09:58:11] <Jeffrey Haas_web_230> as you said tony, it hasn't gotten deployed. so, people are trying to push the solution outward. hence this bof
[09:58:29] <Tony Li_web_233> So we've given up? Sad.
[09:58:45] <Jean-Michel Combes_web_233> @Tony: but we could meet the same "fear" (i.e., drop of legitimate) traffic
[09:59:04] <Mingqing Huang_web_640> @tony, we need all leaves behaving well, but this is impossible :(
[09:59:12] <Tony Li_web_233> Why not?
[10:00:41] <Aijun Wang_web_569> numbers of the leaves are huge
[10:00:58] <Tony Przygienda_web_410> +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] <Tony Li_web_233> 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] <Tony Li_web_233> No
[10:01:38] <Tony Li_web_233> 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 Li_web_233> Tony P. is correct. Once you're in the core, the possible source paths become extremely large.
[10:02:46] <Jeffrey Haas_web_230> Filtering at traditional tier 1 ISPs is impractical. At tier 2, probably impractical. tier 3... possible.
[10:03:01] <Tony Przygienda_web_410> 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] <Tony Li_web_233> Yes, but that filter is on the wrong side of my downlink.
[10:03:40] <Tony Przygienda_web_410> which I agree with ;-) But desperate times breed desperate measures ;-)
[10:04:04] <Tony Przygienda_web_410> I can live in a country with low crime rate or I can invest in crating my windows up ;-)
[10:06:12] <Tony Li_web_233> Please don't talk over the speaker.
[10:06:17] <Jeffrey Haas_web_230> joel, you have open mic
[10:06:19] <Tony Przygienda_web_410> 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] <Job Snijders_web_635> Joel I muted you
[10:06:32] <Joel Halpern_web_532> Oops. Sorry. Thanks Job.
[10:08:27] <Mingqing Huang_web_640> @Jeffrey, cone-based partial deployment might be pratical for first step
[10:09:21] <Jeffrey Haas_web_230> @mingqing incremental deployment makes the network incrementally better for those participating.
[10:09:49] <Jeffrey Haas_web_230> 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] <Pete Resnick_web_576> 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] <Jeffrey Haas_web_230> @pete - dsav or this problem space in general?
[10:10:33] <Pete Resnick_web_576> General.
[10:10:36] <Tony Przygienda_web_410> 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] <Jeffrey Haas_web_230> because it doesn tony.
[10:10:54] <Jari Arkko_web_743> 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] <Jeffrey Haas_web_230> u-rpf is 'easy'. it was a hack.
[10:11:14] <Jeffrey Haas_web_230> @jari "tragedy of the commons"
[10:13:40] <Nan Geng_web_901> dsav looks like multicast but there are some differences. Multipath maybe one of them.
[10:13:49] <Pete Resnick_web_576> @É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] <Jean-Michel Combes_web_233> @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] <Jeffrey Haas_web_230> The presentation isn't really accounting for routing churn as an input at this point.
[10:15:38] <Jeffrey Haas_web_230> Tony P. would probably consider this to be the same as pim tree churn.
[10:16:25] <Nan Geng_web_901> @Jari Agree d. Improving accuracy with bearable cost.
[10:16:36] <Tony Przygienda_web_410> 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] <Jeffrey Haas_web_230> It's one step worse, Tony P. If you charge by the bit, attack traffic is profit. :-)
[10:17:25] <Tony Przygienda_web_410> 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] <Tony Przygienda_web_410> @Jeff: yes, that's where we are today
[10:17:50] <Joel Halpern_web_532> The volume and dynamics were I believe on their open quesitons list.
[10:18:09] <Wes Hardaker_web_192> @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] <Tony Przygienda_web_410> @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] <Joel Halpern_web_532> @Tony P. thanks for joining, and raising perspectives.
[10:22:10] <Jean-Michel Combes_web_233> 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] <Mingqing Huang_web_640> about incentive for one isp, i guess is that one will be able block spoofing traffic coming in self zone
[10:23:27] <Joel Halpern_web_532> @Jean-Michel I think that is a question for the next presentation. This one is intra-domain.
[10:23:55] <Mingqing Huang_web_640> not only just for outgoing traffic
[10:24:30] Nicola Rustignoli_web_342 leaves the room
[10:24:51] <Jean-Michel Combes_web_233> @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] <Mingqing Huang_web_640> the mechnism of DSAV, i think, works for intra- and inter-domain
[10:27:08] <Joel Halpern_web_532> @Jean-Michel The question is valid. And apparently they are now also including inter-domain. COnfuses this co-chair. Sorry.
[10:28:05] <Tony Przygienda_web_410> 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] <Jeffrey Haas_web_230> as someone who operates a mailserver still, tony, I think you're a bit off. :-)
[10:29:24] <Tony Przygienda_web_410> 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] <Tony Przygienda_web_410> yeah, gmail.com is its own story ;-)
[10:30:07] <Benjamin Schwartz_web_837> 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] <Benjamin Schwartz_web_837> or s/networks/routers/ for intra-domain
[10:30:47] Yuexia Fu_web_179 leaves the room
[10:30:47] <Tony Przygienda_web_410> 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] <Joel Halpern_web_532> @Ben I think that is one of the key questions that needs to be explored.
[10:31:54] <Joel Halpern_web_532> Unfortunately, we are out of discussion time. I hope we have a little more at the end.
[10:34:00] <Job Snijders_web_635> i cannot hear the presenter
[10:34:44] <Meetecho> Checking
[10:34:44] <Dan Li_web_311> We will switch to a new presenter
[10:34:57] <Job Snijders_web_635> ok
[10:35:06] <Luigi Iannone_web_142> @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] <Dan Li_web_311> the third presenter has some network problem
[10:35:30] Haojie Wang_web_582 leaves the room
[10:35:32] <Benjamin Schwartz_web_837> Luigi: Agreed, hence why I am more interested in end-to-end validation
[10:35:56] <Job Snijders_web_635> audio is good! thanks
[10:35:59] <Job Snijders_web_635> <3 meetecho
[10:37:40] <Luigi Iannone_web_142> @Ben: meaning BCP 38 like approach?
[10:38:11] <Benjamin Schwartz_web_837> Luigi: I'm hoping for something like ESAV!
[10:38:21] <Yingzhen Qu_web_408> 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] <Luigi Iannone_web_142> @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] <Jeffrey Haas_web_230> 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] <Benjamin Schwartz_web_837> I think the dynamic setup for ESAV seems like a major weakness. I would prefer static config.
[10:41:31] <Benjamin Schwartz_web_837> (^Luigi)
[10:42:06] <Yingzhen Qu_web_408> @Jeff, agreed. same BGPsec story
[10:42:14] <Job Snijders_web_635> I think looking at RPKI as a foundational framework for distribution of crypto thingies is a good approach
[10:42:45] <Jeffrey Haas_web_230> Not quite bgpsec. a bit like aspa
[10:42:59] <Job Snijders_web_635> jared called it "ASPA for packets"
[10:43:33] <Yingzhen Qu_web_408> :)
[10:43:54] <Tony Li_web_233> Crypto in the data plane seems like a non-starter.
[10:44:15] <Jeffrey Haas_web_230> 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] <Benjamin Schwartz_web_837> Tony: Why? It can easily run at line rate.
[10:44:53] <Jeffrey Haas_web_230> 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] <Tony Przygienda_web_410> if it can do that it has to kill aggregation AFAIS which for core is a non starter
[10:45:29] <Eduard V_web_557> The current presentation looks like a 4th label data plane (in addition to MPLS, SRv6, and LISP)
[10:45:37] <Antoine Fressancourt_web_888> I am with Benjamin on this
[10:45:46] <Tony Li_web_233> @Ben: Pointers to routers with line rate at 800Gbps on all ports, please.
[10:46:22] <Tony Przygienda_web_410> 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] <Jeffrey Haas_web_230> rpf on all router architectures I'm familiar with take a line rate hit due to additional lookup for the rpf.
[10:46:30] <Joel Halpern_web_532> @Eduard V - not sure I follow you. This information is not directing forwarding. It is confirming source information validity.
[10:47:03] <Eduard V_web_557> the name of the presentation "data plane approach" then "tag"
[10:47:04] <Jeffrey Haas_web_230> 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] <Tony Li_web_233> And crypto will be more expensive than RPF.
[10:47:12] <Tony Przygienda_web_410> rpf hit is relatively bearable but yeah, those pesky photons and electrons insisting on laws of physics ;-)
[10:47:47] <Jean-Michel Combes_web_233> @Eduard: looks like RFC3514+crypto
[10:47:47] <Jeffrey Haas_web_230> 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] <Tony Li_web_233> Parallelism should work.
[10:48:20] <Tony Przygienda_web_410> ;-) yes, but you pay for speed with gates then ...
[10:48:29] <Jeffrey Haas_web_230> TANSTAAFL
[10:48:53] <Tony Li_web_233> Always
[10:49:06] <Job Snijders_web_635> that comment only applies in capitalist systems! ;-)
[10:49:09] Weiqiang Cheng_web_426 leaves the room
[10:49:28] <Eduard V_web_557> @Jean-Michel Combes: RFC 3514 is 1st of April
[10:49:30] <Tony Li_web_233> In non-capitalist systems, there is no lunch. :)
[10:49:36] <Jeffrey Haas_web_230> Anarcho-collective forwarding engines have a longer consensus model
[10:49:45] <Jean-Michel Combes_web_233> @Eduard: I know :)
[10:49:56] <Tony Przygienda_web_410> the immortal quip of Churchill "capitalism is the worst system, except all the other ones we tried"
[10:50:11] <Jean-Michel Combes_web_233> @Edouard: but the idea is more or less the same I would say
[10:50:17] <Jean-Michel Combes_web_233> *Eduard
[10:51:41] <Eduard V_web_557> @Jean-Michel Combes: thanks. I need to read
[10:52:41] <Jeffrey Haas_web_230> 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] <Jeffrey Haas_web_230> 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] <Tony Przygienda_web_410> agreed. good analogy ...
[10:53:52] <Luigi Iannone_web_142> An this may scale better than a H-by-H approach
[10:54:37] <Jeffrey Haas_web_230> 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] <Tony Przygienda_web_410> 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] <Jeffrey Haas_web_230> This is also the "throw stuff away" bit that I had mentioned to @jean-michel earlier.
[10:55:33] <Tony Przygienda_web_410> 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] <Jeffrey Haas_web_230> 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] <Luigi Iannone_web_142> @Eric: agreed. Incremental deployability is key.
[10:56:30] <Tony Przygienda_web_410> 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] <Jeffrey Haas_web_230> 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] <Tony Przygienda_web_410> ;-)
[10:57:29] Gorry Fairhurst_web_491 joins the room
[10:57:35] <Tony Przygienda_web_410> dropped for your own good BTW ;-)
[10:57:43] <Jeffrey Haas_web_230> I blame Ron Bonica.
[10:57:43] <Tony Li_web_233> 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] <Antoine Fressancourt_web_587> @jeffrey, which presentation are you referring to ?
[10:58:45] <Elmar Bins_web_163> Eric: Has that come up yet this IETF?
[10:59:01] <Tony Li_web_233> IEPG: https://www.youtube.com/watch?v=u2wVZnJ3fo0
[10:59:08] <Elmar Bins_web_163> Ha
[10:59:15] <Tony Li_web_233> 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] <Jeffrey Haas_web_230> @antoine - as usual, chairs haven't gotten their materials posted, so I don't have the easy referral. :-)
[10:59:35] <Jeffrey Haas_web_230> They usually catch up in 2 weeks to 6 months.
[10:59:41] <Jeffrey Haas_web_230> best to unicast them.
[10:59:56] <Antoine Fressancourt_web_587> Thanks for the pointers !
[11:00:03] <Luigi Iannone_web_142> :-) IEPG is delay tolerant
[11:00:10] <Antoine Fressancourt_web_587> Will do :-)
[11:00:48] <Jean-Michel Combes_web_233> IEPG meeting: https://www.potaroo.net/iepg/2022-03-20-ietf113/index.html
[11:02:46] <Luigi Iannone_web_142> thanks Jean
[11:03:26] <Antoine Fressancourt_web_103> Thanks
[11:03:28] <Yingzhen Qu_web_408> I think this is interesting topic, worth exploring
[11:03:33] Ole Trøan_web_407 leaves the room
[11:03:56] <Jari Arkko_web_743> 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] <Benjamin Schwartz_web_837> I think we should aim for something that carries significan benefit at low deployment
[11:04:57] <Tony Li_web_233> IMHO, this seems like a waste of time.
[11:05:01] <Benjamin Schwartz_web_837> 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] <Dan Li_web_311> Thank you everyone
[11:05:32] <Nan Geng_web_901> Thanks