HotRFC @ IETF-105, Montreal Sunday, July 21, 2019, 1800-2000 Info: https://www.ietf.org/how/meetings/105/hotrfc/ Materials: https://datatracker.ietf.org/meeting/105/session/hotrfc ===================================================================== 1. Service Oriented IP Brian E Carpenter (brian.e.carpenter@gmail.com) Service Oriented Internet Protocol (SOIP) proposes a new, backwards-compatible, approach to packet forwarding, where the service required rather than the IP address required acts as the vector for routing packets at the edge of the network. There's a draft (draft-jiang-service-oriented-ip) and there's even some toy code, at https://github.com/becarpenter/tlv. ===================================================================== 2. Asymmetric IPv6 Brian E Carpenter (brian.e.carpenter@gmail.com> Asymmetric IPv6 is a new approach to IPv6 header compression for use in IoT scenarios where minimizing packet size is crucial but routing performance must be maximized. There's a draft (draft-jiang-asymmetric-ipv6). The idea is to make packets shorter without needing a decompression step. ===================================================================== 3. iCAN Do It Liubing (Leo) (leo.liubing@huawei.com) iCAN (instant Congestion Assessment Network) is a mechanism running directly on network nodes: o To adjust the flows paths based on real-time measurement of the candidate paths. o The measurement is to reflect the congestion situation of each path, so that the ingress nodes could decide which flows need to be switched from a path to another. This is something that current SDN and TE technologies can hardly achieve: o Controller is slow and far from the data plane, it is neither able to assess the real-time congestion situation of each path, nor able to assure the data plane always go as expected (especially in SRv6 scenarios). However, iCAN can work with SDN perfectly: controller planning multi-path transmission, and iCAN does the flow optimization automatically. o Traditional TE is not able to adjust the flow paths in real-time. Aim: call for attention and partners Relevance to IETF: This work might be related to TEAS/SPRING/IPPM WGs. ===================================================================== 4. Trustworthy Multipurpose RemoteID (TM-RID) Bob Moskowitz (rgm@labs.htt-consult.com) Stuart Card (stu.card@axenterprize.com) To mitigate the risks presented by Unmanned Aircraft Systems (UAS), the US FAA and other government agencies internationally soon will require, and various bodies are drafting standards for, remote identification. ASTM's proposed Broadcast Remote ID specifies how Unmanned Aircraft (UA) within Line Of Sight (LOS) of an observer can use a one-way RF broadcast to identify themselves and provide other latency-sensitive safety-critical information. ASTM's proposed Network Remote ID specifies how this same information can be obtained, starting from an observed UA's location, via the Internet. All such proposals hinge on a unique ID for each UA, a method whereby this ID (along with operator contact information etc.) can be registered, and a method by which a subsequent ID assertion can be authenticated by authorized parties. Network RemoteID uses the Internet to map current aircraft locations to identities. To avoid being deceived by malicious spoofing of these critical mappings, we need strong authentication. To maintain privacy (from unauthorized eavesdroppers, not from legitimate authorities), we need strong encryption. HIP provides both of these. Thus, we propose to consolidate the 4-tuple of (UA ID, UA physical location, UA onboard host ID, UA onboard host logical location [IP address list]) to a 3-tuple by standardizing the HIP Host Identity Tag (HIT) as a 4th RemoteID type. Depending upon the level of adoption by a given UAS operator, this can provide 3 levels of benefit: 1. Use of the Internet Domain Name System (DNS, the world’s largest distributed database, with well-established update procedures) as a RemoteID registry 2. Strong authentication of not only Network RemoteID but also Broadcast RemoteID messages 3. Rapid establishment of authenticated and encrypted communications with any observed UA that is suitably equipped. We call this “Trustworthy Multipurpose RemoteID (TM-RID)” and have begun preparations for prototyping and experimentation at the New York UAS Test Site. A sidebof will be held Monday at 6pm in room C2. ===================================================================== 5. Mobility Networking Sharon Barkai (sharon.barkai@getnexar.com) Would like to introduce a new draft-rfc we have been working on in the area of mobility, v2v, v2x, networking within the LISP working group. LISP is a set of RFCs dealing with virtual IP and map-assisted-ip-overlays. Over the past decade mobility networks progress was slow and quite stuck for multiple reasons. Many of these reason primarily stem from questionable pre-assumed peer-to-peer model for mobility, and redundant protocol wars that follow - DSRC/c-v2x. Vehicles in most road situations are not really peers, they briefly happen to be in the same place at the same time. An enforced peer to peer model to communicate situations introduces privacy, interoperability, security, timing, and convergence problems which are hard to impossible to solve. As an example, a vehicle reaching a junction and about to turn into an invisible problem (to him) such as construction, jaywalker, double park, school-bus. The problem is clearly visible to cross traffic, but that vehicle may receive multiple, conflicting, or no indications at all from cross cars it doesn't know or trust. To solve this problem we focused strictly on layer3-4 or connectionless brokered mobility sessions. We use the shared-road-location, or geo-state, as the brokering anchor of v2v v2x communications. Nexar, having some of the largest v2v fleets, 10Ks in every major US city, 100Ms miles of ride logs, together with Cisco and academia propose the nexagon draft. Nexagons tiles every road, lane, junction, shoulder, sidewalk with 1sqm H3 hexagons giving each an aggregated unicast and multicast virtual IP (LISP EID) address. These are the in-network geo-state network hexagons enable brokered, verified, private, resilient, LISP based pub-sub exchange of road information. H3 Hexagons offer clear bit operations to track impacted neighboring tiles, clear bitwise geo-spatial hierarchy, approximation of lan-lat-rad that tiles, and algorithmic 64bit HID to 128bit IP EID mapping. We will describe the draft briefly in hotRFC, and few v2v v2x examples including red-light-breach brokered-relayed in under 2msec in lab conditions the largest 5G carrier, as well as real life footage examples from US cities happening daily as time permits. The draft will be discussed at more length in the routing area LISP-WG meeting on July 22. Any questions can be forwarded to lisp@ietf.org or to myself sharon@getnexar.com, or to any of the co-authors listed in the draft. Hope this is clear, attaching a couple links to short video and the draft. https://youtu.be/dK2II3oFzqE https://tools.ietf.org/html/draft-barkai-lisp-nexagon-05 ===================================================================== 6. An open congestion control architecture with network cooperation for RDMA fabric Roni Even (A) (roni.even@huawei.com) The requirement document discusses major problems of current Remote Direct Memory Access (RDMA) fabric technologies and the requirements for better performance. Based on that, the architecture document proposes an open control architecture of hosts and networks for the high performance RDMA fabric to provide better congestion handling for High Performance Computing (HPC) and distributed storage accessing applications which requires low latency and high throughput. We will also have a side meeting to continue the discussion from IETF104. ===================================================================== 7. Strategies to drastically improve congestion control in high performance data centers: next steps for RDMA" Paul Congdon (paul.congdon@tallac.com) In current high-speed Datacenter Networks (DCNs), Remote Direct Memory Access (RDMA) has become the dominant network technology. Congestion control strategies are required to reduce the negative effects of congestion, such as Head-of-Line (HoL) blocking. Among the proposed solutions to mitigate congestion, Explicit Congestion Notification (ECN) and some solutions based on it, are the most popular ones. Unfortunately, the ECN closed-loop mechanism is not able to react in a smooth way under most congestion scenarios. In this talk, we describe the effects that lead the ECN closed-loop mechanism to generate oscillations when congestion is notified to the NICs. We also propose several ideas to improve ECN based on some research we have conducted in the past years. We also invite interested parties to continue the discussion at a scheduled side meeting, Monday 8:30AM - 9:45AM in the Notre Dame room this week, and a proposed non-wg mailing list to be set-up after IETF-105. ===================================================================== 8. Using Service Function Chaining for In-Network Computation Adrien Wion (adrien.wion@telecom-paristech.fr) We present how to augment the routing layer by introducing the notion of service. Our solution leverages on existing distributed routing protocols where, in addition, autonomous nodes announce information about the virtual services they provide. This augmented network view allows NFV-Routers to steer flows through a set of services to propose complex functions in the network. Longer version of this talk will be given @ COINRG Thursday Afternoon. ===================================================================== 9. Networking and Theory Hejianfei (Jeffrey) (jeffrey.he@huawei.com) IETF has active participants from both academic and industrial communities, but the observation is that networking mainly looks an engineering domain, and a good design of protocol depends more on experience from best practice rather than on a systematic knowledge body. Building a good knowledge body(or “theory”) can make it easy for the new generation/new comers not only to inherit but also to make their incremental contribution. Meanwhile , nowadays the industry shows interest in “deterministic” or "bounded delay" services beyond "best effort". This may be a challenge which may require theoretical analysis when exploring the optimal network solutions. Folks, who find this interesting, please email to me to discuss the technical visions and what we can do in IETF potentially. ===================================================================== 10. YANG/RESTCONF for all? Douglas Hubler (douglas@hubler.us) YANG and RESTCONF is associated with just networking but software industry as a whole needs a standard for management plane. Existing management tools require DevOps teams to build integration with existing software services creating fragile, expensive, limited management solutions often with many security vulnerabilities. With "micro services" on the scene, the demands on the management plane gets exponentially higher. I'd like to share my experiences using YANG and RESTCONF for last 4 years for IoT sensors, malware detection systems, public school software, and even a robotic bartender. What can IETF do to extend the scope of these management standards beyond networking? For more information, see freeconf.org. To provide feedback, however small, please reach out to Douglas Hubler (douglas@hubler.us). Love to connect at IETF 105 ! ===================================================================== 11. Democratic Improvement Proposals for decentralization projects Shayan Eskandari (shayan.eskandari@consensys.net) Blockchain and DLT* based systems are waiting in the wings to join the potpourri of core technology that makes up our future digital lives. Both core internet infrastructure technology and many DLT solutions have one thing in common: They are developed with a diverse open source developer community and carry significant security risk. To manage software change related risks both Bitcoin and Ethereum - the second ranked cryptocurrency market - have derived their own process of managing change proposals. For Ethereum changes are discussed and agreed upon in the Ethereum Improvement Proposal (EIP) process. However given the non-hierarchy management model, there have been many approaches and obstacles to make this process as close to a democratic procedure as possible. It is working, but far from perfect and there are many good approaches and lessons learnt. EIP requires input from experts at IETF to shape up and standardize. This proposal is to introduce the EIP process to IETF participants and possibly spring up a BarBof session. For now please feel free to email us to discuss this further, we will create a mailing list when the scope is more defined. Shayan Eskandari: shayan.eskandari@consensys.net Martin Ortner: martin.ortner@consensys.net Previous discussions regarding Security in EIP process: https://youtu.be/Au1Qll-86v0?t=18029 * Distributed Ledger Technology ===================================================================== 12. What is the Next Step of YANG models in the IETF? Qin Wu (bill.wu@huawei.com) Thanks for Routing area YANG model coordination group, IETF YANG architecture design team, YANG Doctors Team, YANG design team in various protocol WGs and IETF YANG coordination group across OPS area and RTG area, considerable huge number of YANG data models are specified springing up like mushroom at high speed since 2014 and used to model devices, e.g., configuration data and operation state and services (for example, the L3VPN Service Model produced by the L3SM working group) They cover many of the networking protocols and techniques. However many such design teams (e.g.,IETF YANG coordination group ,IETF YANG architecture design team) have been closedown around the middle of 2018. There are many YANG models still being specified but move to normal IETF process for standardization. However many operators are not engaged YANG model standardization enough in the IETF. The operators expected to deploy these technologies often don't even know that the standards are being developed. Other operators expected to deploy these technologies may not know how these models work together to configure a device, manage a set of devices involved in a service and which models are fitted into their use case and meet their requirements. This lead to critical new technologies currently being developed without sufficient direct operator input. We want to discuss the next steps for YANG models in the IETF. For people who are interested in YANG data model interconnection framework, please participant in opsawg session on Wednesday 10:00, for people who are interested in the gap between IETF YANG and operator's requirements, please join our side meeting at 8:30PM on Tuesday. We want to understand how operators are looking to use YANG models to provide an integrated top-to-bottom management system based on YANG models, and how the existing models should be integrated. We would especially like to hear from implementers. Feel free to contact me if you are interested or want to engage the discussion. ===================================================================== 13. The Mathematical Mesh Phillip Hallam-Baker (phill@hallambaker.com) Providing usable end-to-end security presents three major problems that are solved by the Mesh 1) Alice wants to read her email, access her web pages from six different devices, how does she manage them 2) Alice needs a means of exchanging contacts with Bob, Carol, etc. How does she do this in person or remotely and how does she call Bob from her phone when she added him on her laptop 3) Managing private keys. If we want Alice to encrypt her stored data we must provide an absolute assurance that there is not the slightest chance of losing it as a result. Otherwise she will keep her encrypted data in the cloud and the unencrypted copy just in case the key is lost. Today we use 1980s cryptography to solve 21st century information security challenges. The Mesh moves the dial forward to the 1990s adding metacryptographic techniques. There are currently 8 drafts and an MIT License reference library. ===================================================================== 14. Topic: Packet Loss Signaling for Encrypted Protocols Lubashev, Igor (ilubashe@akamai.com) Draft: draft-ferrieuxhamchaoui-tsvwg-lossbits Packet loss is a pervasive problem of day-to-day network operation, and proactively detecting, measuring, and locating it is crucial to maintaining high QoS. In a TCP-dominated world, network operators have been heavily relying on information present in the clear in TCP headers: seq and ack numbers, and SACK when enabled. With encrypted protocols, the equivalent transport headers are encrypted and passive packet loss observation is not possible. Since encrypted protocols could be routed by the network differently, and the fraction of Internet traffic delivered using encrypted protocols is increasing every year, it is imperative to measure packet loss experienced by encrypted protocol users directly instead of relying on measuring TCP loss between similar endpoints. We propose adding two explicit loss bits to the clear portion of the protocol headers to restore network operators' ability to maintain high QoS for users of encrypted protocols. These bits can be added to an unencrypted portion of a header belonging to any protocol layer. There will be a side meeting in Sainte-Catherine 8:30am-9:30am on Monday. ===================================================================== 15. Canceled ===================================================================== 16. RESERVED is NOT MUST be zero. Rodney W. Grimes (freebsd@gndrsh.dnsmgr.net) When trying to deploy new or modifications to existing Internet standard protocols frequently the issue comes up that implementations are treating things labeled as reserved by standards as MUST be zero. I would like to propose that we ad RESERVED to the format RFC terminology documents and expand upon the fact that this does not mean that they should be treated as MUST be zero. This also expands into things further than being treated as must be zero in that often things labeled as reserved end up in implmentations as "permanetly forbidden" requiring a revision to the implementation before the reserved items can be used. This is self defeating to the purpose of reservation for future use. Basically reserved has often come to mean immutably forbidden. I can suggest some language that should soften this burden for the future develops of Internet Drafts and standards iff we can actually promote reserved to RESERVED. ===================================================================== 17. DNSSD Discovery Proxy Stuart Cheshire (cheshire@apple.com) DNSSD Discovery Proxy Multicast DNS [RFC6762] is appropriate for small Ethernet networks, but for larger networks, and Wi-Fi networks, IP Multicast can be unreliable, slow, and wasteful of precious wireless spectrum. A DNSSD Discovery Proxy (https://tools.ietf.org/html/draft-ietf-dnssd-hybrid) acts as an intermediary to allow clients to use efficient, reliable, unicast queries to discover existing devices that offer their services using Multicast DNS. Particularly for client devices on Wi-Fi, discovering services on wired Ethernet, this allows the discovery to take place while keeping the IP Multicast traffic isolated to the wired Ethernet, which can handle this traffic much better than Wi-Fi. To engage with this work join us at the DNSSD Working Group meeting on Thursday afternoon, join the DNSSD mailing list, or participate by contributing code and suggestions at our GitHub repository: (https://github.com/IETF-Hackathon/mDNSResponder/). ===================================================================== 18. Application-aware IPv6 networking (APN6) Zhenbin Li (lizhenbin@huawei.com) Shuping Peng (pengshuping@huawei.com) As the Internet is progressing, the decoupling of applications and network transport causes the service provider network pipelined which becomes the bottleneck of the network service development. Moreover a multitude of applications are being carried over the IP network which have varying needs for network bandwidth, latency, jitter, and packet loss, etc. However the network is hard to learn the applications' service requirements which cause it is difficult to provide truly fine-granular traffic operations for the applications and guarantee their SLA requirements. The Application-aware IPv6 Networking (APN6) is to make use of IPv6 extensions header to convey the application related information including its requirements along with the packet to the network so to facilitate the service deployment and network resources adjustment. [I-D.li-6man-app-aware-ipv6-network] proposes the possible work on the application-aware IPv6 networking. We would like to invite the interested parties to continue the discussion at a scheduled side meeting, Thursday 8:30AM - 9:45AM in the Notre Dame room this week, and a proposed a non-wg mailing list to be set-up after IETF-105. ===================================================================== 19. An 'Internet of Rules' Joseph Potvin (jpotvin@xalgorithms.org) An 'Internet of Rules' (IoR) is created when computational algorithms which implement rules can be readily transmitted from any independent source repositories within which they are maintained, to any applications that would use them. A 'rule' is a normative precept by which repeated behaviour is guided through authority, agreement or preference. An 'algorithm' is a posited reusable operational method invoked by a specified data input condition to generate a specified data output result, and then to terminate. However computationally active data probably merits some different treatment than computationally passive data when being transmitted on the Internet. I will step through a 3-minute graphical overview of our 100% free/libre/open specifications, components and system design for a general-purpose request-response IoR service to solve this general class of problem: Agent A, interacting with agent B, would obtain algorithms for one or more externally-managed computational rules from agents C..n, where: * A and B may or may not know about C..n’s rules, or about any updates to them, but either or both would prefer to be notified about relevant rules when interacting. * C…n may or may not know about A and B in particular, nor about their particular medium of interaction, but can expect A or B or their medium of interaction to be capable of exchanging data with a generic medium common to A..n. * A and B would tolerate the risk of exposing limited data through the generic medium in order to learn of applicable rules from C..n. The community is now alpha-testing a working system and invites your constructive criticism and collaboration. Joseph Potvin, the lead for IoR system concepts, looks forward to discussions at IETF 105. All elements are at https://github.com/Xalgorithms (Apache 2.0 license). Slack #ior & Twitter @Xalgorithms In 3-minutes I'll introduce just a few key points from this deck, and will be happy to discuss any elements and ideas throughout the week. https://xalgorithms.org/wp-content/uploads/IoR_System_IETF105_2019-07-16_enPDF.pdf ===================================================================== 20. Use Cases for Provisioning Domains Ted Lemon (mellon@fugue.com) Provisioning Domains (RFC 7556) defined how clients manage different sets of interface information for routing, DNS, and more. This enables multi-path transports, fail-over between different interfaces, and stronger guarantees for how clients separate traffic with different security and privacy needs (VPNs versus unprotected local networks, say). However, RFC 7556 was just the first step. Ongoing work in INTAREA (draft-ietf-intarea-provisioning-domains) is defining how a local router can advertise multiple explicit Provisioning Domains: if your home has multiple uplink providers, this now enables devices to take advantage of the different provider networks as if they are indeed different physical interfaces. Beyond this, we're looking at how we can use Provisioning Domains (PvDs) to help manage tunnels, captive portals, server protocol support, DNS privacy configurations, and more. Please join us in INTAREA and take a look at draft-ietf-intarea-provisioning-domains if you're interested! =====================================================================