Minutes IETF112: irtfopen
minutes-112-irtfopen-00

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/