IRTF Open Meeting ================= Tuesday, 9 November 2021, at 16:00-18:00 UTC Room: Room 4 Chair: Colin Perkins Minutes: Mat Ford ## Introduction and Status Update IRTF Chair Slides: https://datatracker.ietf.org/meeting/112/materials/slides-112-irtfopen-irtf-open-meeting-agenda-for-ietf-112-01 ## xBGP: When You Can’t Wait for the IETF and Vendors Thomas Wirtgen Slides: https://datatracker.ietf.org/meeting/112/materials/slides-112-irtfopen-xbgp-when-you-cant-wait-for-ietf-and-vendors-00 Paper: https://nsg.ee.ethz.ch/fileadmin/user_upload/publications/hotnet023-wirtgenA.pdf Eliot Lear: Very interesting talk. Referring to your last slide - was your desire for this mechanism to always have the transitive bit set to zero? - That would allow for a certain amount of prototyping. TW: Yes. xBGP is designed for quick prototyping. We just add an interface to allow some network operators to implement quickly this functionality, test in another network and if it works well then it might be released on the production routing network. If you would like to have good performance but would need to write it directly in the implementation. When you introduce new code you will break some BGP protocol rules, but we designed mechanism to guarantee local execution but execution in the global network is not done. You test on yourself, if confident then push to global network. There is no way to test the global safety of the implementation. Maybe this is something we can do after all, but it is quite complicated to verify the security properties of the global network. Eliot Lear: One of the reasons the standardisation process takes a long time is because routing is a difficult business to begin with and we do see cases where routes disappear even with the current mature mechanisms so there's a certain amount of prove time. How flexible should a routing paradigm be, and what are the guard rails that make it safe to experiment? TW: This is an interesting question. With xBGP you can do pretty much anything. You have to choose the right tool to guarantee the security property of the router. We write all our code in C which is not really secure. We could use safer languages, e.g. Rust, those tools may provide better security. There is a balance between flexibility and security. If you add flexibility inside routing protocol then security aspects may be lessened. CP: This adds hooks throughout BGP implementation for insertion of new functionality. How much of the core protocol has to be implemented in the core and how much can be implemented in these programmable hooks? TW: To put xBGP inside an implementation we first had to follow original RFC 4271 and we also need all the multi-protocol extensions. In the paper we reproduce route-reflector functionality. This is a use case that proves that you can implement a lot of complexity. The strong basis of xBGP relies on the original BGP draft and multi-protocol extensions. You can put your code inside the extension code and then put it in the implementation which is xBGP compatible. But to modify data structure ... you cannot. For example if you take the functionality that enlarge the buffer of BGP 4k to 74KB of memory to one message this is one example of a feature that you cannot do in xBGP. So everything related to memory data structure is really inside the implementation. CP: The focus of the mechanism is extensibility of the protocols. It's well known that IETF process takes time. Eliot mentioned some of the reasons for that. Assuming we can't make the IETF go faster, are there things we should be doing differently in the way we structure protocols that would help make this sort of extensibility work easier? Are there any general lessons we can learn? Or is this very specific to BGP? TW: When we look at xBGP - the protocol was pretty well established. What we try to do in xBGP is to understand what are the properties of the protocol and then establish a set of properties to model a general architecture of the routing protocol. If general model is implemented inside implementation then xBGP can be embedded but more exotic implementations prohibit that. CP: So general conclusion is that modularity in the way the specs are written might make this process easier - maybe something for standardisation groups to think about. ## Analyzing Third Party Service Dependencies in Modern Web Services: Have We Learned from the Mirai-Dyn Incident Aqsa Kashaf Slides: https://datatracker.ietf.org/meeting/112/materials/slides-112-irtfopen-analyzing-third-party-service-dependencies-in-modern-web-services-have-we-learned-from-the-mirai-dyn-incident-00 Paper: https://dl.acm.org/doi/10.1145/3419394.3423664 Wes Montgomery: Thanks for the work - any studies on centralisation and dependencies are fantastic as it's definitely a trend as you have proved in your numbers. You said you recommend companies be more transparent - do you have any data that proves that is a good thing for them to do? AK: I have multiple data points. I'm working in DDoS area, so when I say companies should be more transparent I mean more transparent about the attacks they are experiencing so we can determine the skill level of the attackers. In the Dyn attack we don't really know if the target was Dyn or some other website and everyone else was just collateral damage. If the latter then also having a private provider could help. If a particular provider was being attacked then maybe we should be ... Other attacks, e.g. building attackers that do reconnaissance on different service providers. DDoS reports talk about attacks that have existed for a long time, but we don't really know how to detect, different techniques - it's important to know what the capabilities of existing attackers are. Eliot Lear: Great paper - really helpful in an area that is really challenging. The numbers you presented in terms of concentration are consistent with numbers from Anna Maria Mandalari from Imperial College showed when she was looking at IoT cloud dependencies (presented at IMC as well). There's an activity in IETF that may benefit from hearing about this work - Benoit Claise work on SAIN (Service Assurance for Intent-Based Networking) which is a service architecture based on a dependency graph. Lots of work going on in the ops and network management area focussed on this important question of resiliency. Congratulations on the great paper I look forward to seeing more interesting work from you and your colleagues. ## Come as You Are: Helping Unmodified Clients Bypass Censorship with Server-side Evasion Kevin Bock Slides: https://datatracker.ietf.org/meeting/112/materials/slides-112-irtfopen-come-as-you-are-helping-unmodified-clients-bypass-censorship-with-server-side-evasion-00 Paper: https://www.cs.umd.edu/~dml/papers/geneva_sigcomm20.pdf Wes Montgomery: How did you determine ground truth for whether something is successful or not and got transferred to and from the client correctly? KB: In our case we have the good fortune of being able to control both the client and the server, so we did our experiments, and we had vantage points located in all of these censored countries so ground truth was very easy to determine. So we try to obtain some forbidden resource see if the censor takes action, then try again with server side strategy running and see it succeed. Scaling up to more real-world deployment or where client isn't controlled it does start getting more difficult - need to use telemetry. Most censor actions are pretty obvious. Generally the server can determine pretty accurately whether the censor has taken action or not. Shivan Sahib: Were you thinking about coming up with strategies in a centralised way and then distributing strategies to every server running Geneva, or were you thinking every server deployment would devise it's own strategies? KB: For initial roll-out the methodology has been that there's a strategy oracle that provides strategies. There are two self-contained components to Geneva - component that runs the strategy on the network and the genetic algorithm that discovers strategies, so it's a natural way to proceed. For now we've had success with having 3rd parties deploy the strategy engine and we're more of the strategy oracle. That said, there are more and more groups finding strategies for themselves so as that becomes more and more decentralised things will continue to improve. Mirja Kühlewind: Thanks for the talk. We talked about the cat and mouse game in the chat. What's the time lag between strategies being discovered and censors reacting? KB: Great question, something we're still studying is what does it look like when a nation state rolls out a bugfix. We don't have a great understanding of this yet. Part of this is the limitation of dealing with scaling - different parts of large countries may have many instances of middleboxes. Takes a concerted effort to measure these things at scale and get a good understanding of how the fixes move through the network. We're definitely interested in understanding how fixes roll out. MK: I'll read your next paper. Andrew Campling: I can see nation states have the resources to respond over time with counter-measures, but my concern is for typical end-user against malicious content developer, server-side evasions in the hands of malware has pretty negative implications for vast majority of Internet users. Any tool can be used for good and bad. I think this tool has negative connotations for vast majority of users. Doesn't negate the work but needs very careful consideration. KB: It's a true statement generally that something like this can be used for good and bad. Malicious is in the eye of the beholder. We consciously haven't targeted our work against the kind of content firewalls you're describing. It's hard to quantify who's in the majority here - there are billions of people living under censored regimes, also billions that would like to be protected by firewalls. It's something we have been thinking about and was a serious consideration when we thought about whether to release the tool. Decided best to put it out there and let the community use it. Andrew Campling: Early adopters of encrypted DNS were malware developers, so malicious content in a definition that most of us would recognise as malicious. CP: It's a difficult problem. Tempted to say that the only winning move is not to play. Can you say something about how you did the tests and how you protected users running the tests in these countries? KB: In these cases we developed these tests ourselves, so there were no end-users directly involved. We tried very hard to not put any end users at risk. As these things are deployed in future, that's a whole separate question. That's something that as people deploy these things we'll have to wrestle with those. But so far we've had no user involvement. CP: Thanks! Great talks, great discussion. Please follow up with authors to chat more throughout the meeting or in the gather space. And please submit nominations for ANRP 2022 - deadline is end of next week. Recordings of the talks, and links to the papers, are available from https://irtf.org/anrp/