[{"author": "Jeffrey Haas", "text": "SAV table is effectively superset of FIB.<br/>", "time": "2022-03-24T09:22:29Z"}, {"author": "Mingqing Huang", "text": "yeah, adding more asymmetric source prefix info<br/>", "time": "2022-03-24T09:23:53Z"}, {"author": "Joel Halpern", "text": "Thanks to whomever adjusted the mic hight.&nbsp;&nbsp;Folks in room need to be very close to the microphone.<br/>", "time": "2022-03-24T09:26:22Z"}, {"author": "Job Snijders", "text": "Thank Jared :)<br/>", "time": "2022-03-24T09:26:51Z"}, {"author": "Job Snijders", "text": "does anyone have an empty sheet of paper for me?<br/>", "time": "2022-03-24T09:27:00Z"}, {"author": "Jeffrey Haas", "text": "@ted I think what you're trying to discuss is covered by what the underlying existing u-rpf features are intended to accomplish?<br/>", "time": "2022-03-24T09:29:43Z"}, {"author": "\u00c9ric Vyncke", "text": "<a href=\"https://datatracker.ietf.org/doc/html/rfc8704\" rel=\"nofollow\">https://datatracker.ietf.org/doc/html/rfc8704</a><br/>", "time": "2022-03-24T09:31:53Z"}, {"author": "Joel Halpern", "text": "Mengxiao, please wait until we call on you.<br/>", "time": "2022-03-24T09:34:27Z"}, {"author": "Jeffrey Haas", "text": "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.<br/>", "time": "2022-03-24T09:34:53Z"}, {"author": "Pete Resnick", "text": "Giuseppe is a bit quiet in the room. Could someone type his comment here?<br/>", "time": "2022-03-24T09:35:12Z"}, {"author": "Job Snijders", "text": "joel - did you catch it?<br/>", "time": "2022-03-24T09:35:37Z"}, {"author": "Mingqing Huang", "text": "from my understanding, current uRPF-based tools more focus on access and northbound protection, not so good for east-west bound and southbound<br/>", "time": "2022-03-24T09:36:56Z"}, {"author": "Mingqing Huang", "text": "which is very import for one ISP perspective<br/>", "time": "2022-03-24T09:37:53Z"}, {"author": "Job Snijders", "text": "@Tim - it seems someone jumped in front of you! Please hold, you'll be next<br/>", "time": "2022-03-24T09:38:01Z"}, {"author": "Job Snijders", "text": "we are cutting the queue after Jeff Haas!<br/>", "time": "2022-03-24T09:42:22Z"}, {"author": "Job Snijders", "text": "to move on to the protocol proposals<br/>", "time": "2022-03-24T09:42:36Z"}, {"author": "Jean-Michel Combes", "text": "+1 with Jared: especially for Tiers-1 who have a large customers cone ...<br/>", "time": "2022-03-24T09:42:46Z"}, {"author": "Jeffrey Haas", "text": "I'll save my comments for the proposal space.<br/>", "time": "2022-03-24T09:44:28Z"}, {"author": "Job Snijders", "text": "ok<br/>", "time": "2022-03-24T09:44:53Z"}, {"author": "Giuseppe Fioccola", "text": "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?<br/>", "time": "2022-03-24T09:45:01Z"}, {"author": "Tony Li", "text": "It can help, but it cannot fix all problems.<br/>", "time": "2022-03-24T09:45:34Z"}, {"author": "Jeffrey Haas", "text": "Partial answer to Jared's observation is that local router knowledge is incomplete for a given AS in BGP.&nbsp;&nbsp;If you can get global routing knowledge within the AS, you can augment local router knowledge.&nbsp;&nbsp;That's most of rfc 8704.<br/>", "time": "2022-03-24T09:45:53Z"}, {"author": "Jeffrey Haas", "text": "Past that point, you have to decide what you don't know and then add it to the set of info.<br/>", "time": "2022-03-24T09:46:11Z"}, {"author": "Tony Li", "text": "Higher level question: are we solving the right problem? We seem to have jumped into the very hard problem of transitive verification.<br/>", "time": "2022-03-24T09:46:31Z"}, {"author": "Jeffrey Haas", "text": "^<br/>", "time": "2022-03-24T09:46:40Z"}, {"author": "Tony Przygienda", "text": "@Tony L: +1<br/>", "time": "2022-03-24T09:46:47Z"}, {"author": "Tony Li", "text": "BCP 38 tried (and failed) to solve the very simple question of local verification.<br/>", "time": "2022-03-24T09:46:58Z"}, {"author": "Tony Li", "text": "Fixing that seems to be 99.999% of the problem.<br/>", "time": "2022-03-24T09:47:15Z"}, {"author": "Jeffrey Haas", "text": "For edge networks, bcp38 can do a very good job.<br/>", "time": "2022-03-24T09:47:23Z"}, {"author": "Tony Przygienda", "text": "yepp, once we start to talk path validation instead of origin validation we are pretty soon in BGPSEC territory anyway<br/>", "time": "2022-03-24T09:47:29Z"}, {"author": "Jeffrey Haas", "text": "rfc 8704 indirectly says you can use RPKI ROAs to seed your augmented state. :-)<br/>", "time": "2022-03-24T09:48:02Z"}, {"author": "Giuseppe Fioccola", "text": "Dan Li replies to me that does not completely solve the problem. It is similar to feasible uRPF.<br/>", "time": "2022-03-24T09:48:03Z"}, {"author": "Tony Li", "text": "We didn't get BCP 38 deployed. How do we things differently so that eyeball networks enable it?<br/>", "time": "2022-03-24T09:48:06Z"}, {"author": "\u00c9ric Vyncke", "text": "The incentive is indeed a key Q<br/>", "time": "2022-03-24T09:48:28Z"}, {"author": "Jeffrey Haas", "text": "The incentive is easy: when you have networks that are known to not implement bcp 38, you drop their packets.<br/>", "time": "2022-03-24T09:48:56Z"}, {"author": "\u00c9ric Vyncke", "text": "meetcho: we lost slides<br/>", "time": "2022-03-24T09:48:56Z"}, {"author": "Meetecho", "text": "Checking<br/>", "time": "2022-03-24T09:49:15Z"}, {"author": "\u00c9ric Vyncke", "text": "problem sovled<br/>", "time": "2022-03-24T09:49:20Z"}, {"author": "Meetecho", "text": "Ack<br/>", "time": "2022-03-24T09:49:31Z"}, {"author": "Mingqing Huang", "text": "yeah, we have to pay some cost to cover the limitation casused by local intelligence<br/>", "time": "2022-03-24T09:49:35Z"}, {"author": "Jean-Michel Combes", "text": "@Jeffrey: hope this is a joke ...<br/>", "time": "2022-03-24T09:49:59Z"}, {"author": "Jeffrey Haas", "text": "A very grim one, @jean-michel.<br/>", "time": "2022-03-24T09:50:15Z"}, {"author": "Jeffrey Haas", "text": "If your security model needs to not deal with spoofing, you lock things down.<br/>", "time": "2022-03-24T09:50:34Z"}, {"author": "Jeffrey Haas", "text": "if your security model isn't strict (usual general Internet case), you decide what you do about incomplete filtering<br/>", "time": "2022-03-24T09:51:00Z"}, {"author": "Jeffrey Haas", "text": "remember this methodology is not strictly about general ISP case for end users - it applies to stricter security scenarios as well.<br/>", "time": "2022-03-24T09:52:12Z"}, {"author": "Jean-Michel Combes", "text": "@Jeffrey: \"be conservative in what you send, be liberal in what you accept\" ... something you forgot? :)<br/>", "time": "2022-03-24T09:52:40Z"}, {"author": "Jeffrey Haas", "text": "@jean-michel: \"My network, my rules\".<br/>", "time": "2022-03-24T09:53:03Z"}, {"author": "Jean-Michel Combes", "text": "@Jeffrey: '\"my network, my business\" I would say*<br/>", "time": "2022-03-24T09:53:41Z"}, {"author": "Tony Przygienda", "text": "@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 ;-)<br/>", "time": "2022-03-24T09:53:42Z"}, {"author": "Jeffrey Haas", "text": "^<br/>", "time": "2022-03-24T09:53:56Z"}, {"author": "Tony Li", "text": "&lt;Insert Tony's regular chant&gt;<br/>", "time": "2022-03-24T09:54:32Z"}, {"author": "Tony Li", "text": "Insert Tony's regular chant.<br/>", "time": "2022-03-24T09:54:47Z"}, {"author": "Jean-Michel Combes", "text": "The main issue regarding uRPF is that network operators are afraid to drop legitimate traffic<br/>", "time": "2022-03-24T09:55:11Z"}, {"author": "Jean-Michel Combes", "text": "and uRPF is a black box<br/>", "time": "2022-03-24T09:55:24Z"}, {"author": "Jeffrey Haas", "text": "A valid concern for general purpose cases.<br/>", "time": "2022-03-24T09:55:32Z"}, {"author": "Tony Przygienda", "text": "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 ;-)<br/>", "time": "2022-03-24T09:55:33Z"}, {"author": "Jari Arkko", "text": "Avoiding dropping legitimate packets is goodness<br/>", "time": "2022-03-24T09:55:42Z"}, {"author": "\u00c9ric Vyncke", "text": "Or some operators are lazy / do not care or even are hostile ?<br/>", "time": "2022-03-24T09:55:43Z"}, {"author": "Tony Li", "text": "There are several cases of that.<br/>", "time": "2022-03-24T09:57:07Z"}, {"author": "Jeffrey Haas", "text": "to earlier comments, Eric, bcp 38 implemented pervasively at the edges solves most of the real things people are concerned about for spoofing.&nbsp;&nbsp;In the absence of it, you're passing the tax to try to do something almost as good further into the network.<br/>", "time": "2022-03-24T09:57:12Z"}, {"author": "Jeffrey Haas", "text": "and transitively, the closer you get to the internet core the harder it is to do it right<br/>", "time": "2022-03-24T09:57:26Z"}, {"author": "Tony Li", "text": "So why not fix the problem at the leaves?<br/>", "time": "2022-03-24T09:57:41Z"}, {"author": "Jean-Michel Combes", "text": "@Tony: that was the goal with SAVI<br/>", "time": "2022-03-24T09:58:01Z"}, {"author": "Jeffrey Haas", "text": "as you said tony, it hasn't gotten deployed.&nbsp;&nbsp;so, people are trying to push the solution outward.&nbsp;&nbsp;hence this bof<br/>", "time": "2022-03-24T09:58:12Z"}, {"author": "Tony Li", "text": "So we've given up? Sad.<br/>", "time": "2022-03-24T09:58:30Z"}, {"author": "Jean-Michel Combes", "text": "@Tony: but we could meet the same \"fear\" (i.e., drop of legitimate) traffic<br/>", "time": "2022-03-24T09:58:46Z"}, {"author": "Mingqing Huang", "text": "@tony, we need all leaves behaving well, but this is impossible :(<br/>", "time": "2022-03-24T09:59:05Z"}, {"author": "Tony Li", "text": "Why not?<br/>", "time": "2022-03-24T09:59:13Z"}, {"author": "Aijun Wang", "text": "numbers of the leaves are huge<br/>", "time": "2022-03-24T10:00:42Z"}, {"author": "Tony Przygienda", "text": "+1&nbsp;&nbsp;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<br/>", "time": "2022-03-24T10:00:59Z"}, {"author": "Tony Li", "text": "So? If everyone filters their own network, it's easy.<br/>", "time": "2022-03-24T10:01:02Z"}, {"author": "\u00c9ric Vyncke", "text": "and would you blindly trust all leaves ?<br/>", "time": "2022-03-24T10:01:10Z"}, {"author": "Tony Li", "text": "No<br/>", "time": "2022-03-24T10:01:15Z"}, {"author": "Tony Li", "text": "Trust, but verify. And when that fails, what can we do?<br/>", "time": "2022-03-24T10:01:39Z"}, {"author": "\u00c9ric Vyncke", "text": "Better than nothing.... I agree<br/>", "time": "2022-03-24T10:01:53Z"}, {"author": "Tony Li", "text": "Tony P. is correct. Once you're in the core, the possible source paths become extremely large.<br/>", "time": "2022-03-24T10:02:11Z"}, {"author": "Jeffrey Haas", "text": "Filtering at traditional tier 1 ISPs is impractical.&nbsp;&nbsp;At tier 2, probably impractical.&nbsp;&nbsp;tier 3... possible.<br/>", "time": "2022-03-24T10:02:47Z"}, {"author": "Tony Przygienda", "text": "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 ;-)<br/>", "time": "2022-03-24T10:03:02Z"}, {"author": "Tony Li", "text": "Yes, but that filter is on the wrong side of my downlink.<br/>", "time": "2022-03-24T10:03:26Z"}, {"author": "Tony Przygienda", "text": "which I agree with ;-) But desperate times breed desperate measures ;-)<br/>", "time": "2022-03-24T10:03:41Z"}, {"author": "Tony Przygienda", "text": "I can live in a country with low crime rate or I can invest in crating my windows up ;-)<br/>", "time": "2022-03-24T10:04:05Z"}, {"author": "Tony Li", "text": "Please don't talk over the speaker.<br/>", "time": "2022-03-24T10:06:13Z"}, {"author": "Jeffrey Haas", "text": "joel, you have open mic<br/>", "time": "2022-03-24T10:06:18Z"}, {"author": "Tony Przygienda", "text": "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 ;-)<br/>", "time": "2022-03-24T10:06:20Z"}, {"author": "\u00c9ric Vyncke", "text": "Joel we hear you...<br/>", "time": "2022-03-24T10:06:21Z"}, {"author": "Job Snijders", "text": "Joel I muted you<br/>", "time": "2022-03-24T10:06:28Z"}, {"author": "Joel Halpern", "text": "Oops.&nbsp;&nbsp;Sorry.&nbsp;&nbsp;Thanks Job.<br/>", "time": "2022-03-24T10:06:33Z"}, {"author": "Mingqing Huang", "text": "@Jeffrey, cone-based partial deployment might be pratical for first step<br/>", "time": "2022-03-24T10:08:28Z"}, {"author": "Jeffrey Haas", "text": "@mingqing incremental deployment makes the network incrementally better for those participating.<br/>", "time": "2022-03-24T10:09:22Z"}, {"author": "Jeffrey Haas", "text": "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.<br/>", "time": "2022-03-24T10:09:50Z"}, {"author": "Pete Resnick", "text": "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.<br/>", "time": "2022-03-24T10:10:01Z"}, {"author": "Jeffrey Haas", "text": "@pete - dsav or this problem space in general?<br/>", "time": "2022-03-24T10:10:24Z"}, {"author": "Pete Resnick", "text": "General.<br/>", "time": "2022-03-24T10:10:34Z"}, {"author": "Tony Przygienda", "text": "randomly musing: why does this look like PIM uRPF ;-)<br/>", "time": "2022-03-24T10:10:37Z"}, {"author": "\u00c9ric Vyncke", "text": "It seems simple but the amount of states and messages is huge<br/>", "time": "2022-03-24T10:10:42Z"}, {"author": "Jeffrey Haas", "text": "because it doesn tony.<br/>", "time": "2022-03-24T10:10:46Z"}, {"author": "Jari Arkko", "text": "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.<br/>", "time": "2022-03-24T10:10:55Z"}, {"author": "Jeffrey Haas", "text": "u-rpf is 'easy'.&nbsp;&nbsp;it was a hack.<br/>", "time": "2022-03-24T10:10:56Z"}, {"author": "Jeffrey Haas", "text": "@jari \"tragedy of the commons\"<br/>", "time": "2022-03-24T10:11:15Z"}, {"author": "Nan Geng", "text": "dsav looks like multicast but there are some differences. Multipath maybe one of them.<br/>", "time": "2022-03-24T10:13:41Z"}, {"author": "Pete Resnick", "text": "@\u00c9ric: 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.<br/>", "time": "2022-03-24T10:13:50Z"}, {"author": "Jean-Michel Combes", "text": "@Jari: this is the goal of the MANRS initiative (i.e., to build a community of ISPs willing to improve Internet security)<br/>", "time": "2022-03-24T10:14:06Z"}, {"author": "Jeffrey Haas", "text": "The presentation isn't really accounting for routing churn as an input at this point.<br/>", "time": "2022-03-24T10:14:28Z"}, {"author": "Jeffrey Haas", "text": "Tony P. would probably consider this to be the same as pim tree churn.<br/>", "time": "2022-03-24T10:15:39Z"}, {"author": "Nan Geng", "text": "@Jari Agree d. Improving accuracy with bearable cost.<br/>", "time": "2022-03-24T10:16:26Z"}, {"author": "Tony Przygienda", "text": "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&nbsp;&nbsp;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.<br/>", "time": "2022-03-24T10:16:37Z"}, {"author": "Jeffrey Haas", "text": "It's one step worse, Tony P.&nbsp;&nbsp;If you charge by the bit, attack traffic is profit. :-)<br/>", "time": "2022-03-24T10:17:13Z"}, {"author": "Tony Przygienda", "text": "yeah, this is 100% PIM churn before learning first scaling lessons (periodic RIP readvert are fun but only for very short time ;-)<br/>", "time": "2022-03-24T10:17:26Z"}, {"author": "Tony Przygienda", "text": "@Jeff: yes, that's where we are today<br/>", "time": "2022-03-24T10:17:40Z"}, {"author": "Joel Halpern", "text": "The volume and dynamics were I believe on their open quesitons list.<br/>", "time": "2022-03-24T10:17:51Z"}, {"author": "Wes Hardaker", "text": "@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.<br/>", "time": "2022-03-24T10:18:10Z"}, {"author": "Tony Przygienda", "text": "@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 ;-)<br/>", "time": "2022-03-24T10:19:17Z"}, {"author": "\u00c9ric Vyncke", "text": "It is not the IPv6 extension header hop-by-hop<br/>", "time": "2022-03-24T10:19:27Z"}, {"author": "\u00c9ric Vyncke", "text": "BoF are always the most interesting sessions IMHO (at least for me)<br/>", "time": "2022-03-24T10:20:26Z"}, {"author": "Joel Halpern", "text": "@Tony P. thanks for joining, and raising perspectives. <br/>", "time": "2022-03-24T10:21:10Z"}, {"author": "Jean-Michel Combes", "text": "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?<br/>", "time": "2022-03-24T10:22:11Z"}, {"author": "Mingqing Huang", "text": "about incentive for one isp, i guess is that one will be able block spoofing traffic coming in self zone<br/>", "time": "2022-03-24T10:23:02Z"}, {"author": "Joel Halpern", "text": "@Jean-Michel I think that is a question for the next presentation.&nbsp;&nbsp;This one is intra-domain.<br/>", "time": "2022-03-24T10:23:28Z"}, {"author": "Mingqing Huang", "text": "not only just for outgoing traffic<br/>", "time": "2022-03-24T10:23:56Z"}, {"author": "Jean-Michel Combes", "text": "@Joel: good point - I missed this was related to intra-domain, sorry<br/>", "time": "2022-03-24T10:24:52Z"}, {"author": "\u00c9ric Vyncke", "text": "@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<br/>", "time": "2022-03-24T10:25:19Z"}, {"author": "Mingqing Huang", "text": "the mechnism of DSAV, i think, works for intra- and inter-domain<br/>", "time": "2022-03-24T10:27:06Z"}, {"author": "Joel Halpern", "text": "@Jean-Michel The question is valid.&nbsp;&nbsp;And apparently they are now also including inter-domain.&nbsp;&nbsp;&nbsp;&nbsp;COnfuses this co-chair.&nbsp;&nbsp;Sorry.<br/>", "time": "2022-03-24T10:27:09Z"}, {"author": "Tony Przygienda", "text": "you could build something that back-pressures&nbsp;&nbsp;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 ...<br/>", "time": "2022-03-24T10:28:06Z"}, {"author": "Jeffrey Haas", "text": "as someone who operates a mailserver still, tony, I think you're a bit off. :-)<br/>", "time": "2022-03-24T10:28:57Z"}, {"author": "Tony Przygienda", "text": "so do I and good luck trying to send/receive stuff if you don't have a good cert ...<br/>", "time": "2022-03-24T10:29:25Z"}, {"author": "\u00c9ric Vyncke", "text": "esp to gmail.com indeed<br/>", "time": "2022-03-24T10:29:42Z"}, {"author": "Tony Przygienda", "text": "yeah, gmail.com is its own story ;-)<br/>", "time": "2022-03-24T10:29:55Z"}, {"author": "Benjamin Schwartz", "text": "I don't get the trust model.&nbsp;&nbsp;If I trust these notifications, why don't I trust these networks to just do their own filtering?<br/>", "time": "2022-03-24T10:30:08Z"}, {"author": "\u00c9ric Vyncke", "text": ";-)<br/>", "time": "2022-03-24T10:30:18Z"}, {"author": "Benjamin Schwartz", "text": "or s/networks/routers/ for intra-domain<br/>", "time": "2022-03-24T10:30:43Z"}, {"author": "Tony Przygienda", "text": "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 ...<br/>", "time": "2022-03-24T10:30:48Z"}, {"author": "\u00c9ric Vyncke", "text": "I guess it is more to be sure that packet drop at the edge can be done<br/>", "time": "2022-03-24T10:30:59Z"}, {"author": "Joel Halpern", "text": "@Ben I think that is one of the key questions that needs to be explored.<br/>", "time": "2022-03-24T10:31:23Z"}, {"author": "Joel Halpern", "text": "Unfortunately, we are out of discussion time.&nbsp;&nbsp;I hope we have a little more at the end.<br/>", "time": "2022-03-24T10:31:55Z"}, {"author": "Job Snijders", "text": "i cannot hear the presenter<br/>", "time": "2022-03-24T10:34:01Z"}, {"author": "Meetecho", "text": "Checking<br/>", "time": "2022-03-24T10:34:45Z"}, {"author": "Dan Li", "text": "We will switch to a new presenter<br/>", "time": "2022-03-24T10:34:45Z"}, {"author": "Job Snijders", "text": "ok<br/>", "time": "2022-03-24T10:34:58Z"}, {"author": "Luigi Iannone", "text": "@Ben: I think that as soon as you trust a router you are open to attacks. Messages need to be authenticated and validated.<br/>", "time": "2022-03-24T10:35:07Z"}, {"author": "Dan Li", "text": "the third presenter has some network problem<br/>", "time": "2022-03-24T10:35:07Z"}, {"author": "Benjamin Schwartz", "text": "Luigi: Agreed, hence why I am more interested in end-to-end validation<br/>", "time": "2022-03-24T10:35:33Z"}, {"author": "Job Snijders", "text": "audio is good! thanks<br/>", "time": "2022-03-24T10:35:57Z"}, {"author": "Job Snijders", "text": "&lt;3 meetecho<br/>", "time": "2022-03-24T10:36:00Z"}, {"author": "Luigi Iannone", "text": "@Ben: meaning BCP 38 like approach?<br/>", "time": "2022-03-24T10:37:41Z"}, {"author": "Benjamin Schwartz", "text": "Luigi: I'm hoping for something like ESAV!<br/>", "time": "2022-03-24T10:38:12Z"}, {"author": "Yingzhen Qu", "text": "think what if an attacker can break into the relay of messages? so I guess the assumption is the between router communication is safe<br/>", "time": "2022-03-24T10:38:22Z"}, {"author": "Luigi Iannone", "text": "@Ben: the advantage I see for DSAV is that it may be more effective against DDoS. ESAV may be a victim of DDoS.<br/>", "time": "2022-03-24T10:40:44Z"}, {"author": "Jeffrey Haas", "text": "Yingzhen, the security model is effectively the same as that of BGP itself, and definitely the security of any central controller driven network.<br/>", "time": "2022-03-24T10:41:15Z"}, {"author": "Benjamin Schwartz", "text": "I think the dynamic setup for ESAV seems like a major weakness.&nbsp;&nbsp;I would prefer static config.<br/>", "time": "2022-03-24T10:41:19Z"}, {"author": "Benjamin Schwartz", "text": "(^Luigi)<br/>", "time": "2022-03-24T10:41:32Z"}, {"author": "Yingzhen Qu", "text": "@Jeff, agreed. same BGPsec story<br/>", "time": "2022-03-24T10:42:07Z"}, {"author": "Job Snijders", "text": "I think looking at RPKI as a foundational framework for distribution of crypto thingies is a good approach<br/>", "time": "2022-03-24T10:42:15Z"}, {"author": "Jeffrey Haas", "text": "Not quite bgpsec.&nbsp;&nbsp;a bit like aspa<br/>", "time": "2022-03-24T10:42:46Z"}, {"author": "Job Snijders", "text": "jared called it \"ASPA for packets\"<br/>", "time": "2022-03-24T10:43:00Z"}, {"author": "Yingzhen Qu", "text": ":)<br/>", "time": "2022-03-24T10:43:34Z"}, {"author": "Tony Li", "text": "Crypto in the data plane seems like a non-starter.<br/>", "time": "2022-03-24T10:43:55Z"}, {"author": "Jeffrey Haas", "text": "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\"<br/>", "time": "2022-03-24T10:44:16Z"}, {"author": "Benjamin Schwartz", "text": "Tony: Why?&nbsp;&nbsp;It can easily run at line rate.<br/>", "time": "2022-03-24T10:44:47Z"}, {"author": "Jeffrey Haas", "text": "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<br/>", "time": "2022-03-24T10:44:54Z"}, {"author": "Tony Przygienda", "text": "if it can do that it has to kill aggregation AFAIS which for core is a non starter<br/>", "time": "2022-03-24T10:44:54Z"}, {"author": "Eduard V", "text": "The current presentation looks like a 4th label data plane (in addition to MPLS, SRv6, and LISP)<br/>", "time": "2022-03-24T10:45:30Z"}, {"author": "Antoine Fressancourt", "text": "I am with Benjamin on this<br/>", "time": "2022-03-24T10:45:38Z"}, {"author": "Tony Li", "text": "@Ben: Pointers to routers with line rate at 800Gbps on all ports, please.<br/>", "time": "2022-03-24T10:45:47Z"}, {"author": "Tony Przygienda", "text": "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<br/>", "time": "2022-03-24T10:46:23Z"}, {"author": "Jeffrey Haas", "text": "rpf on all router architectures I'm familiar with take a line rate hit due to additional lookup for the rpf.<br/>", "time": "2022-03-24T10:46:28Z"}, {"author": "Joel Halpern", "text": "@Eduard V - not sure I follow you.&nbsp;&nbsp;This information is not directing forwarding.&nbsp;&nbsp;It is confirming source information validity.<br/>", "time": "2022-03-24T10:46:31Z"}, {"author": "Eduard V", "text": "the name of the presentation \"data plane approach\" then \"tag\"<br/>", "time": "2022-03-24T10:47:04Z"}, {"author": "Jeffrey Haas", "text": "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.<br/>", "time": "2022-03-24T10:47:05Z"}, {"author": "Tony Li", "text": "And crypto will be more expensive than RPF.<br/>", "time": "2022-03-24T10:47:09Z"}, {"author": "Tony Przygienda", "text": "rpf hit is relatively bearable but yeah, those pesky photons and electrons insisting on laws of physics ;-)<br/>", "time": "2022-03-24T10:47:13Z"}, {"author": "Jean-Michel Combes", "text": "@Eduard: looks like RFC3514+crypto<br/>", "time": "2022-03-24T10:47:48Z"}, {"author": "Jeffrey Haas", "text": "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.<br/>", "time": "2022-03-24T10:47:48Z"}, {"author": "Tony Li", "text": "Parallelism should work.<br/>", "time": "2022-03-24T10:48:20Z"}, {"author": "Tony Przygienda", "text": ";-) yes, but you pay for speed with gates then ...<br/>", "time": "2022-03-24T10:48:21Z"}, {"author": "Jeffrey Haas", "text": "TANSTAAFL<br/>", "time": "2022-03-24T10:48:30Z"}, {"author": "Tony Li", "text": "Always<br/>", "time": "2022-03-24T10:48:54Z"}, {"author": "Job Snijders", "text": "that comment only applies in capitalist systems! ;-)<br/>", "time": "2022-03-24T10:49:07Z"}, {"author": "Eduard V", "text": "@Jean-Michel Combes: RFC 3514 is 1st of April<br/>", "time": "2022-03-24T10:49:29Z"}, {"author": "Tony Li", "text": "In non-capitalist systems, there is no lunch. :)<br/>", "time": "2022-03-24T10:49:31Z"}, {"author": "Jeffrey Haas", "text": "Anarcho-collective forwarding engines have a longer consensus model<br/>", "time": "2022-03-24T10:49:37Z"}, {"author": "Jean-Michel Combes", "text": "@Eduard: I know :)<br/>", "time": "2022-03-24T10:49:46Z"}, {"author": "Tony Przygienda", "text": "the immortal quip of Churchill \"capitalism is the worst system, except all the other ones we tried\"<br/>", "time": "2022-03-24T10:49:57Z"}, {"author": "Jean-Michel Combes", "text": "@Edouard: but the idea is more or less the same I would say<br/>", "time": "2022-03-24T10:50:12Z"}, {"author": "Jean-Michel Combes", "text": "*Eduard<br/>", "time": "2022-03-24T10:50:18Z"}, {"author": "Eduard V", "text": "@Jean-Michel Combes: thanks. I need to read<br/>", "time": "2022-03-24T10:51:42Z"}, {"author": "Jeffrey Haas", "text": "By analogy, esav appears to be SFC carried out among cooperating ASes where the service function is validation<br/>", "time": "2022-03-24T10:52:42Z"}, {"author": "\u00c9ric Vyncke", "text": "Good summary<br/>", "time": "2022-03-24T10:52:59Z"}, {"author": "Jeffrey Haas", "text": "Deep crypto isn't super helpful in many respects.&nbsp;&nbsp;You need enough sprinkled in there to not worry about external spoofing of it through routers that aren't protected.<br/>", "time": "2022-03-24T10:53:45Z"}, {"author": "Tony Przygienda", "text": "agreed. good analogy ...<br/>", "time": "2022-03-24T10:53:47Z"}, {"author": "Luigi Iannone", "text": "An this may scale better than a H-by-H approach<br/>", "time": "2022-03-24T10:53:53Z"}, {"author": "Jeffrey Haas", "text": "Tagging is not a bad idea; it can help.&nbsp;&nbsp;But it still means solve the prior problem better: you need a correct rpf graph.<br/>", "time": "2022-03-24T10:54:38Z"}, {"author": "\u00c9ric Vyncke", "text": "@Luigi it seems so, also easier for incremental deployment but tagging all packets...<br/>", "time": "2022-03-24T10:55:01Z"}, {"author": "Tony Przygienda", "text": "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<br/>", "time": "2022-03-24T10:55:12Z"}, {"author": "Jeffrey Haas", "text": "This is also the \"throw stuff away\" bit that I had mentioned to @jean-michel earlier.<br/>", "time": "2022-03-24T10:55:21Z"}, {"author": "Tony Przygienda", "text": "tags could scale and you could re-tag as well. It's basically MPLS in another flavor and that is fast enough we know<br/>", "time": "2022-03-24T10:55:34Z"}, {"author": "\u00c9ric Vyncke", "text": "inserting header is a NO GO<br/>", "time": "2022-03-24T10:55:48Z"}, {"author": "Jeffrey Haas", "text": "if the trust model is cooperative then you don't need to stack tags, just replace with a \"trusted by union of parties\" tag<br/>", "time": "2022-03-24T10:56:17Z"}, {"author": "Luigi Iannone", "text": "@Eric: agreed. Incremental deployability is key.<br/>", "time": "2022-03-24T10:56:20Z"}, {"author": "Tony Przygienda", "text": "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<br/>", "time": "2022-03-24T10:56:31Z"}, {"author": "\u00c9ric Vyncke", "text": "draft-vyncke-v6ops-james (sorry for the ads) to hceck whether ext header travels the global Internet<br/>", "time": "2022-03-24T10:56:33Z"}, {"author": "Jeffrey Haas", "text": "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.<br/>", "time": "2022-03-24T10:57:14Z"}, {"author": "Tony Przygienda", "text": ";-)<br/>", "time": "2022-03-24T10:57:24Z"}, {"author": "Tony Przygienda", "text": "dropped for your own good BTW ;-)<br/>", "time": "2022-03-24T10:57:36Z"}, {"author": "Jeffrey Haas", "text": "I blame Ron Bonica.<br/>", "time": "2022-03-24T10:57:44Z"}, {"author": "Tony Li", "text": "If we're going to do that, let's just put the full path in the header. We can call it 6vRS.<br/>", "time": "2022-03-24T10:57:44Z"}, {"author": "\u00c9ric Vyncke", "text": "What about IPv10 ?<br/>", "time": "2022-03-24T10:58:08Z"}, {"author": "Antoine Fressancourt", "text": "@jeffrey, which presentation are you referring to ?<br/>", "time": "2022-03-24T10:58:17Z"}, {"author": "Elmar Bins", "text": "Eric: Has that come up yet this IETF?<br/>", "time": "2022-03-24T10:58:46Z"}, {"author": "Tony Li", "text": "IEPG: <a href=\"https://www.youtube.com/watch?v=u2wVZnJ3fo0\" rel=\"nofollow\">https://www.youtube.com/watch?v=u2wVZnJ3fo0</a><br/>", "time": "2022-03-24T10:59:02Z"}, {"author": "Elmar Bins", "text": "Ha<br/>", "time": "2022-03-24T10:59:09Z"}, {"author": "Tony Li", "text": "Sorry, slides don't look like they're available.<br/>", "time": "2022-03-24T10:59:16Z"}, {"author": "\u00c9ric Vyncke", "text": "BTW, please join savnet@ietf.org<br/>", "time": "2022-03-24T10:59:18Z"}, {"author": "Jeffrey Haas", "text": "@antoine - as usual, chairs haven't gotten their materials posted, so I don't have the easy referral. :-)<br/>", "time": "2022-03-24T10:59:19Z"}, {"author": "Jeffrey Haas", "text": "They usually catch up in 2 weeks to 6 months.<br/>", "time": "2022-03-24T10:59:36Z"}, {"author": "Jeffrey Haas", "text": "best to unicast them.<br/>", "time": "2022-03-24T10:59:42Z"}, {"author": "Antoine Fressancourt", "text": "Thanks for the pointers !<br/>", "time": "2022-03-24T10:59:57Z"}, {"author": "Luigi Iannone", "text": ":-) IEPG is delay tolerant<br/>", "time": "2022-03-24T11:00:04Z"}, {"author": "Antoine Fressancourt", "text": "Will do :-)<br/>", "time": "2022-03-24T11:00:11Z"}, {"author": "Jean-Michel Combes", "text": "IEPG meeting: <a href=\"https://www.potaroo.net/iepg/2022-03-20-ietf113/index.html\" rel=\"nofollow\">https://www.potaroo.net/iepg/2022-03-20-ietf113/index.html</a><br/>", "time": "2022-03-24T11:00:49Z"}, {"author": "Luigi Iannone", "text": "thanks Jean<br/>", "time": "2022-03-24T11:02:47Z"}, {"author": "Antoine Fressancourt", "text": "Thanks<br/>", "time": "2022-03-24T11:03:27Z"}, {"author": "Yingzhen Qu", "text": "I think this is interesting topic, worth exploring<br/>", "time": "2022-03-24T11:03:29Z"}, {"author": "Jari Arkko", "text": "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.<br/>", "time": "2022-03-24T11:03:57Z"}, {"author": "\u00c9ric Vyncke", "text": "Correct, shared opinion Jari<br/>", "time": "2022-03-24T11:04:20Z"}, {"author": "Benjamin Schwartz", "text": "I think we should aim for something that carries significan benefit at low deployment<br/>", "time": "2022-03-24T11:04:36Z"}, {"author": "Tony Li", "text": "IMHO, this seems like a waste of time.<br/>", "time": "2022-03-24T11:04:58Z"}, {"author": "Benjamin Schwartz", "text": "End-to-end systems often have this property, since they do not rely on any intermediary routers to do anything<br/>", "time": "2022-03-24T11:05:02Z"}, {"author": "\u00c9ric Vyncke", "text": "Thank you all<br/>", "time": "2022-03-24T11:05:11Z"}, {"author": "Dan Li", "text": "Thank you everyone<br/>", "time": "2022-03-24T11:05:13Z"}, {"author": "Nan Geng", "text": "Thanks<br/>", "time": "2022-03-24T11:05:33Z"}]