Do you have an idea, problem space, or proposal that IETFers should hear about?
Do you want to propose IETF or IRTF work but aren’t sure if your idea is ready or who will be interested?
Agenda requests are now being accepted for the Request for Conversation (HotRFC) lightning talk session. Presenters will submit a 4 minute video to make their case for collaboration. Interested folks can continue the discussion online. Goals include encouraging brainstorming conversations, helping new work proposals find collaborators, raising awareness of relevant work going on elsewhere, and promoting BarBoFs. Past HotRFC topics covered a broad range of topics:
Collaboration: proposals for new standards work or new research topics that haven’t been discussed elsewhere, potentially relevant research that may be ready for the IETF
Notification: new topics on the agenda in a working group or research group, cross-area IETF work
Enlightenment: updates on relevant technologies, industry advances that could affect IETF participants.
With strict time limits, concise talks will give viewers a sense of whether they’d like to know more and, importantly, coordinates on how to do so.
We’re going to try to preserve the value of this session while adapting it to a fully online meeting and leveraging the virtual-world capabilities of Gather. Keep in mind this is an experiment and feedback is welcome to improve it should we be in this situation again. With that as prologue, here is how we’ll do it this time:
Draft agenda of talks is here
Pascal Urien, Telecom Paris, France
Abstract: The goal of the IOSE project is to deploy on-line vaults, based on secure elements for internet users. These vaults provide secure storage and tamper resistant computing resources, using open technologies. To reach these goals IOSE provides two interfaces: administrative interface for secure downloading of applications within secure elements, and service interface (TLS1.3 based) for remote use of these resources. Two protocols described by IETF drafts are involved, RACS (Remote APDU Secure), and TLS-SE (TLS for Secure Element). Open code is available at github for IOSE servers (win32, ubuntu, raspberry pi) and secure elements (i.e. javacards). At this moment the project main focus is the design of IOSE servers, and the security protocol required to transfer the exclusive ownership of secure element resources to their end user. Nevertheless, the whole infrastructure comprises multiple entities, such as application provider, service provider, infrastructure provider, SE-App provider, in order to efficiently deploy, on-demand, secure resources.
Contact: Pascal.Urien@telecom-paris.fr
Resources:
https://www.ietf.org/archive/id/draft-urien-coinrg-iose-04.txt
https://datatracker.ietf.org/doc/html/draft-urien-tls-se-03
https://datatracker.ietf.org/doc/html/draft-urien-tls-im-05
https://datatracker.ietf.org/doc/html/draft-urien-core-racs-15
https://github.com/purien/IoSE
Video: https://www.youtube.com/watch?v=dxw7kMijz34
Spencer Dawkins, Tencent America LLC
Abstract: At a side meeting at IETF 111, there was considerable interest in specifying RTP (Real-time Transport Protocol) over QUIC. It is common to use SDP (Session Description Protocol) to set up RTP sessions between endpoints, and SDP descriptions communicate transport parameters, which include any information that the endpoints need to know, in order to set up an RTP session, so we need to add new SDP “proto” attribute values, and describe how the endpoints use SDP Offer/Answer to set up an RTP session that will use QUIC. I want to talk to people who could make use of RTP over QUIC, in order to understand what’s necessary in SDP to support their applications. If you’re knowledgeable about RTP, SDP, or QUIC, you’re also invited, of course!
Contact information and coordinates: I’m spencerdawkins.ietf@gmail.com. I’ll be in the HotRFC poster area of Gather after the IETF plenary, I’ll update this description to include coordinates for a side meeting during IETF 112, when the IETF 112 side meeting wiki page is set up.
Fabio Bulgarella (Telecom Italia - TIM)
Abstract: The latency Spin Bit has been adopted by the QUIC transport protocol but is rarely implemented for privacy concerns (the RTT may roughly reveal the distance between client and server). The algorithm of the Delay Bit (or even the Spin Bit) can be slightly modified to mask the RTT of the connection to an intermediate observer. This result can be achieved using a simple expedient which consists in delaying the client-side reflection of the delay sample (or the spin edge) by a pre-determined time value. This leads an observer to measure a wrong RTT greater than the real one. Nonetheless, the observer-server component of the delay remains valid and can be used to measure network performance.
Here useful information about the follow up of HotRFC presentation:
Involved draft (IPPM)
Explicit Flow Measurements (draft-mdt-ippm-explicit-flow-measurements)
https://datatracker.ietf.org/doc/html/draft-mdt-ippm-explicit-flow-measurements-02
Our contacts
Mauro Cociglio (mauro.cociglio@telecomitalia.it)
Massimo Nilo (massimo.nilo@telecomitalia.it)
Fabio Bulgarella (fabio.bulgarella@guest.telecomitalia.it)
Phill Hallam-Baker (phill@hallambaker.com)
Abstract: Providing credentials to end users has been considered a hard problem for over 30 years. The WebPKI and DNSSEC are widely used to identify organizations but no PKI has established a similar position for credentialing people. While S/MIME is widely used, the PKI part is really just vouching for the organization. OpenPGP tries to meet this need but applies a model that only the most sophisticated users can understand.
But what if the problem isn’t the PKI part at all? The WebPKI and DNSSEC are both built on the DNS naming scheme and DNS is designed to identify machines and organizations, not people.
What if we started with a naming system that was designed to be a naming system for people first and foremost and build it around an append only log such that registration of the name created an a-priori binding to the holder’s public key?
The Mesh Callsign service was originally designed to allow Mesh users to change service providers without switching costs by posting ‘change of address’ notice to a central registry.
Unlike previous schemes built on blockchain technologies, no proof of work, proof of stake or any other form of proof of waste is required to finalize the callsign registry entries. Every user acts as their own ultimate root of trust.
Coordinates to learn more:
MathMesh.com
Mathematical Mesh 3.0 Part VII: Mesh Callsign Service (ietf.org)
(Will have updated draft by the talk)
Yihao Jia (jiayihao@huawei.com), Luigi Iannone
Abstract: The Internet Protocol (IP) has been the major technological success in information technology of the last half century. As the Internet becomes pervasive, IP has been replacing communication technology for many domain-specific solutions. However, there are specific scenarios that showcase possibly different addressing requirements, which are challenging to be accommodated in the IP addressing model. These scenarios highlight issues related to the Internet addressing model and call for starting a discussion on a way to re-think/evolve the addressing model so to better accommodate different domain-specific requirements.
Related I-D.:
Relevant activities:
Adrian Farrel, Old Dog Consulting (adrian@olddog.co.uk)
Abstract: We’ll be holding an open side meeting to discuss some recent research on Service Routing and Addressing, and to bring some speakers into the IETF community. There will be time to ask questions and discuss the implications for routing and for research. This HotRFC slot will serve to introduce the speakers and purpose of the meeting. It’s a teaser to get you to come to the side meeting.
More info at : https://github.com/danielkinguk/sarah/tree/main/conferences/ietf-112
Video: https://youtu.be/xY3urcOCRw0
Daniel King, Lancaster University (daniel@olddog.co.uk)
Abstract: There has been research and discussion of a number of ways to route on more information than classical IP addresses. This is known as semantic routing and may involve routing on additional fields in packets, or adding additional semantics to IP addresses. The idea is to have an RG to encourage research and debate semantic routing systems and architectures to include considerations of limited domains and their interconnection, additional routing functions, and the scaling and stability of systems with different routing semantics. It should examine the challenges faced by routing systems in the Internet as pressure is placed on them by increasing demands from applications for predictable, differentiated, quality-enhanced connectivity, and service functions.
More information at : https://github.com/danielkinguk/sarah/tree/main/RAISE
Video: https://youtu.be/7_MsHQzOMA8
Dirk von Hugo (Dirk.von-Hugo@telekom.de) & Behcet Sarikaya (sarikaya@ieee.org)
Abstract: Talk attempts to discuss hardware based Internet of Things authentication and evaluate on related issues within a future networking area beyond 5G going into 6G for standardization.
To learn more:
Video: https://youtu.be/0AFfuHLYyBY
Stephen McQuistin, University of Glasgow (sm@smcquistin.uk)
Abstract: In this talk, I’ll introduce our recent paper, "Characterising the IETF Through the Lens of RFC Deployment”, which describes a large-scale empirical study of IETF activities, with a focus on understanding collaborative activities, and how these underpin the publication of RFCs. Using a dataset of 2.4 million emails, 8,711 RFCs and 4,512 authors, we examined the shifts and trends within the standards development process, showing how protocol complexity and time to produce standards has increased. With these observations in mind, we developed statistical models to understand the factors that lead to successful uptake and deployment of protocols, deriving insights to improve the standardisation process.
More information: https://sodestream.github.io/paper-characterising-the-ietf-through-the-lens-of-rfc-deployment.html
Yangfei Guo. THUCSNET laboratory, Tsinghua University, P. R. China. (guoyangf19@mails.tsinghua.edu.cn)
Abstract: We propose an mechanism about Inter-Domain Source Address Validation. We call this mechanism as SAVA-X: An Inter-Domain Source Address Validation Architecture, which has a control plane and a data plane.
Control plane of SAVA-X synchronizes information about different domains and maintains state machines to generate tags for using in identifying the correctness of IP source address of packets,
Data plane of SAVA-X is composed with all border routers of domains, which accepts information and tags from the control plane and add, validate, or remove tag option to/from the packet.
We have submitted three related drafts. You could get it from:
Video: https://youtu.be/4CCnSkOjeW8
Alexander Clemm, Futurewei
Abstract: New use cases are emerging that depend on the ability of networks to provide high-precision network services with stringent end-to-end service-level guarantees. This will require advances in the way such services can be accounted for and metrics that can be used for that.
We propose to define a set of metrics for high-precision networking services. Specifically, those metrics do not merely capture service levels such as latency, but the degree of compliance with which service levels are being delivered relative to service level objectives that were defined for the flow. The metrics are very efficient to maintain and can be used as part of flow records and/or accounting records. They can also be used to continuously monitor the quality with which high-precision networking service are being delivered.
More information: https://datatracker.ietf.org/doc/html/draft-csfx-ippm-hipmetrics
Our contacts:
Alexander Clemm ludwig@clemm.org
John Strassner strazpdj@gmail.com
Jerome Francois jerome.francois@inria.fr