| |
|
| |
| | CBOR Web Token (CWT) Claims in COSE Headers |
| |
|
This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any COSE structure. This functionality helps to facilitate applications that wish to make use of CBOR Web Token (CWT) claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. |
| | Using DNSSEC Authentication of Named Entities (DANE) with DNS Service Bindings (SVCB) and QUIC |
| |
|
Service Binding (SVCB) records introduce a new form of name indirection in DNS. They also convey information about the endpoint's supported protocols, such as whether QUIC transport is available. This document specifies how DNS-Based Authentication of Named Entities (DANE) interacts with Service Bindings to secure connections, including use of port numbers and transport protocols discovered via SVCB queries. The "_quic" transport name label is introduced to distinguish TLSA records for DTLS and QUIC. |
| | SMTP Service Extension for Client Identity |
| |
|
This document defines an extension for the Simple Mail Transfer Protocol (SMTP) called "CLIENTID" to provide a method for clients to indicate an identity to the server. This identity is an additional token that may be used for security and/or informational purposes, and with it a server may optionally apply heuristics using this token. |
| | IMAP Service Extension for Client Identity |
| |
|
This document defines an Internet Message Access Protocol (IMAP) service extension called "CLIENTID" which provides a method for clients to indicate an identity to the server. This identity is an additional token that may be used for security and/or informational purposes, and with it a server may optionally apply heuristics using this token. |
| | LibrePGP Message Format |
| |
|
This document specifies the message formats used in LibrePGP. LibrePGP is an extension of the OpenPGP format which provides encryption with public-key or symmetric cryptographic algorithms, digital signatures, compression and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the LibrePGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document is based on: RFC 4880 (OpenPGP), RFC 5581 (Camellia in OpenPGP), and RFC 6637 (Elliptic Curves in OpenPGP). |
| | Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 |
| |
|
This document allocates code points for the use of RSASSA-PKCS1-v1_5 with client certificates in TLS 1.3. This removes an obstacle for some deployments to migrate to TLS 1.3. |
| | RADIUS accounting via IPFIX |
| |
|
The Remote Authentication Dial In User Server (RADIUS) Protocol provides for a number of simple session-based metrics. There is a need to increase the number of metrics, and to add metrics for individual flows within a session. This document leverages IP Flow Information Export (IPFIX) to address both needs. |
| |
|
| |
| | Near Real Time Mirroring (NRTM) version 4 |
| |
| | draft-ietf-grow-nrtm-v4-03.txt |
| | Date: |
26/11/2023 |
| | Authors: |
Sasha Romijn, Job Snijders, Edward Shryane, Stavros Konstantaras |
| | Working Group: |
Global Routing Operations (grow) |
|
This document specifies a one-way synchronization protocol for Internet Routing Registry (IRR) records. The protocol allows instances of IRR database servers to mirror IRR records, specified in the Routing Policy Specification Language (RPSL), between each other. |
| | A well-known BGP community to denote prefixes used for Anycast |
| |
|
In theory routing decisions on the Internet and by extension within ISP networks should always use hot-potato routing to reach any given destination. In reality operators sometimes choose to not use the hot-potato paths to forward traffic due to a variety of reasons, mostly motivated by traffic engineering considerations. For prefixes carrying anycast traffic in virtually all situations it is advisable to stick to the hot-potato principle. As operators mostly don't know which prefixes are carrying unicast or anycast traffic, they can't differentiate between them in their routing policies. To allow operators to take well informed decisions on which prefixes are carrying anycast traffic this document proposes a well-known BGP community to denote this property. |
| | OSPF Graceful Restart Enhancements |
| |
|
This document describes enhancements to the OSPF graceful restart procedures to improve routing convergence in some OSPF network deployments. This document updates RFC 3623 and RFC 5187. |
| | Service Function Chaining (SFC) Parallelism and Diversions |
| |
|
Service Function Chaining (SFC) is the processing of packets through a sequence of Service Functions (SFs) within an SFC domain by the addition of path information and metadata on entry to that domain, the use and modification of that path information and metadata to step the packet through a sequence of SFs, and the removal of that path information and metadata on exit from that domain. The IETF has standardized a method for SFC using the Network Service Header specified in RFC 8300. There are requirements for SFC to process packets through parallel sequences of service functions, rejoining thereafter, and to easily splice in additional service functions or splice service functions out of a service chain. The IETF has received a liaison from International Telecommunication Union (ITU) indicating their interest in such requirements. This document provides use cases and specifies extensions to SFC to support these requirements. |
| | Realizing Network Slices in IP/MPLS Networks |
| |
| | draft-ietf-teas-ns-ip-mpls-03.txt |
| | Date: |
26/11/2023 |
| | Authors: |
Tarek Saad, Vishnu Beeram, Jie Dong, Bin Wen, Daniele Ceccarelli, Joel Halpern, Shaofu Peng, Ran Chen, Xufeng Liu, Luis Contreras, Reza Rokui, Luay Jalil |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by relying on compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) on to packets that carry identifiers that indicate the slicing service that is to be applied to the packets. |
| |
|
| |
| | EVPN All Active Usage Enhancement |
| |
|
A principal feature of EVPN is the ability to support multihoming from a customer equipment (CE) to multiple provider edge equipment (PE) active with all-active links. This draft specifies an improvement to load balancing such links. |
| | EVPN VXLAN Bypass VTEP |
| |
|
A principal feature of EVPN is the ability to support multihoming from a customer equipment (CE) to multiple provider edge equipment (PE) with all-active links. This draft specifies a mechanism to simplify PEs used with VXLAN tunnels and enhance VXLAN Active-Active reliability. |
| | Distributed Ledger Time-Stamp |
| |
| | draft-intesigroup-dlts-07.txt |
| | Date: |
22/11/2023 |
| | Authors: |
Emanuele Cisbani, Daniele Ribaudo, Giuseppe Damiano |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a standard to extend Time Stamp Tokens with Time Attestations recorded on Distributed Ledgers. The aim is to provide long-term validity to Time Stamp Tokens, backward compatible with currently available software. |
| | BGP Extensions for Source Address Validation Networks (BGP SAVNET) |
| |
| | draft-geng-idr-bgp-savnet-03.txt |
| | Date: |
22/11/2023 |
| | Authors: |
Nan Geng, Zhenbin Li, Zhen Tan, Mingxing Liu, Dan Li, Fang Gao |
| | Working Group: |
Individual Submissions (none) |
|
Many source address validation (SAV) mechanisms have been proposed for preventing source address spoofing. However, existing SAV mechanisms are faced with the problems of inaccurate validation or high operational overhead in some scenarios. This document proposes BGP SAVNET by extending BGP protocol for SAV. This protocol can propagate SAV-related information through BGP messages. The propagated information will help edge/border routers automatically generate accurate SAV rules. These rules construct a validation boundary for the network and help check the validity of source addresses of arrival data packets. |
| | SR based Loop-free implementation |
| |
|
Microloops are brief packet loops that occur in the network following a topology change (link down, link up, node fault, or metric change events). Microloops are caused by the non-simultaneous convergence of different nodes in the network. If nodes converge and send traffic to a neighbor node that has not converged yet, traffic may be looped between these two nodes, resulting in packet loss,jitter, and out-of-order packets. This document presents some optional implementation methods aimed at providing loop avoidance in the case of IGP network convergence event in different scenarios. |
| | The DNS-Based scheme to revoke certificates in Transport Layer Security (TLS) Protocol: TLSR |
| |
|
This memo presents the definition of a new DNS resouce record type named TLSR, and then discusses a new framework for certificate revocation and certificate status verification. This document can solve the existing problems in the current certificate revocation schemes. This requires matching improvements in TLS client software, but no change in TLS server software. |
| | Deterministic Networks - Navigating Precision in Communication |
| |
|
This document offers a comprehensive overview of deterministic networks, elucidating their significance, key characteristics, and the challenges they address in comparison to non-deterministic counterparts. With a focus on Time-Sensitive Networking (TSN) and Precision Time Protocol (PTP), the technological aspects are explored, encompassing synchronization mechanisms, traffic shaping, and security considerations. Real-world applications in industrial automation, control systems, and multimedia streaming underscore the practical relevance of deterministic networks. The document emphasizes the importance of precise time synchronization, security measures, and collaboration within the networking community. Through acknowledgments, the collaborative efforts of the Deterministic Networking (DetNet) Working Group, authors of relevant standards, and the broader community are recognized, highlighting the collective dedication to advancing deterministic networking technologies. |
| |
|
| |
| | BGP MVPN in IPv6 Infrastructure Networks: Problems and Solution Approaches |
| |
|
MVPN deployment faces some problems while used in provider's IPv6 infrastructure networks. This document describes these problems, and corresponding solutions. |
| | Multicast VPN Upstream Designated Forwarder Selection |
| |
|
This document defines Multicast Virtual Private Network (VPN) extensions and procedures of designated forwarder election performed between ingress PEs, which is different from the one described in [RFC9026] in which the upstream designated forwarder determined by using the "Standby PE Community" carried in the C-Multicast routes. Based on the DF election, the failure detection point discovery mechanism between DF and standby DF is extended in MVPN procedures to achieve fast failover by using BFD session to track the status of detection point. To realize a stable "warm root standby", this document obsolete the P-Tunnel status determining procedure for downstream PEs in regular MVPN by introducing a RPF Set Checking mechanism as an instead. |
| | Control Plane of Inter-Domain Source Address Validation Architecture |
| |
| | draft-xu-savax-control-06.txt |
| | Date: |
21/11/2023 |
| | Authors: |
Ke Xu, Jianping Wu, Xiaoliang Wang, Yangfei Guo |
| | Working Group: |
Individual Submissions (none) |
|
Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. The inter-domain source address validation architecture is an effort to enhance the Internet by using state machines to generate consistent tags. When communicating between two end hosts at different ADs of the IPv6 network, tags will be added to the packets to identify the authenticity of the IPv6 source address. |
| | Data Plane of Inter-Domain Source Address Validation Architecture |
| |
| | draft-xu-savax-data-05.txt |
| | Date: |
21/11/2023 |
| | Authors: |
Ke Xu, Jianping Wu, Xiaoliang Wang, Yangfei Guo |
| | Working Group: |
Individual Submissions (none) |
|
Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. The inter-domain source address validation architecture is an effort to enhance the Internet by using state machines to generate consistent tags. When communicating between two end hosts at different ADs of the IPv6 network, tags will be added to the packets to identify the authenticity of the IPv6 source address. This memo focuses on the data plane of the SAVA-X mechanism. |
| | Communication Protocol Between the AD Control Server and the AD Edge Router of Inter-Domain Source Address Validation Architecture |
| |
|
Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. The inter-domain source address validation architecture is an effort to enhance the Internet by using state machines to generate consistent tags. When communicating between two end hosts at different ADs of the IPv6 network, tags will be added to the packets to identify the authenticity of the IPv6 source address. This memo focuses on the data plane of the SAVA-X mechanism. |
| | IBM i Telnet Enhancements |
| |
|
This obsoletes RFC4777 with an enhanced Automatic Sign-On PBKDF2 with HMAC SHA-512 password hash available with systems running with V7R5M0 or later and configured to use Password Level (QPWDLVL) 4 or higher for the user profile passwords Section 5.3. Require use of Transport Layer Security (TLS) to secure the telnet session between the Telnet server and client Section 13. Add Telnet Device Negotiation Termination Section 10.5 documenting how telnet clients that do not follow 5250 negotiation are handled. Document use of Transport Layer Security (TLS) using port 992 Section 14. Enhancement to add Multi Factor Authentication to automatic sign-on Changes since -00 Draft * Update abstract for PBKDF2 with HMAC SHA-512 password hash * Document use of Transport Layer Security (TLS) in Security Considerations Section 13 Changes since -01 Draft * TLS handshake must complete before invite for terminal type is sent in Section 2 * Change using TLS from RECOMENDED to REQUIRED to be ccompliant with this draft Section 13 * Change disabling port 23 from RECOMENDED to REQUIRED Section 13 * Detail use and related DCM configuration for TLS Section 13 * Add IANA Considerations use of port 992 for Telnet using TLS/SSL (service telnet-ssl) to Section 14 * Include "application definition" and "Digital Certificate Manager (DCM)" to Section 1.1 * Update abstract for Authentication factor in Section 5 * Update Response Codes for Authentication factor in Section 10.4 |
| | Flooding Reduction in CLOS Networks |
| |
|
In a CLOS topology, an OSPF (or ISIS) router may receive identical copies of an LSA (or LSP) from multiple OSPF (or ISIS) neighbors. Moreover, two OSPF (or ISIS) neighbors may exchange the same LSA (or LSP) simultaneously. This results in unnecessary flooding of link- state information, which wastes the precious resources of OSPF (or ISIS) routers. Therefore, this document proposes extensions to OSPF (or ISIS) to reduce this flooding within CLOS networks. The reduction of OSPF (or ISIS) flooding is highly beneficial for improving the scalability of CLOS networks. |
| |
|
| |
| | Architecture and Framework for IPv6 over Non-Broadcast Access |
| |
|
This document presents an architecture for IPv6 access networks that decouples the network-layer concepts of Links, Interface, and Subnets from the link-layer concepts of links, ports, and broadcast domains, and limits the reliance on link-layer broadcasts. This architecture is suitable for IPv6 over any network, including non-broadcast networks, which is typically the case for intangible media such as wireless and overlays. A study of the issues with IPv6 ND over intangible media is presented, and a framework to solve those issues within the new architecture is proposed. |
| | Verifiable Distributed Aggregation Functions |
| |
| | draft-irtf-cfrg-vdaf-08.txt |
| | Date: |
20/11/2023 |
| | Authors: |
Richard Barnes, David Cook, Christopher Patton, Phillipp Schoppmann |
| | Working Group: |
Crypto Forum (cfrg) |
|
This document describes Verifiable Distributed Aggregation Functions (VDAFs), a family of multi-party protocols for computing aggregate statistics over user measurements. These protocols are designed to ensure that, as long as at least one aggregation server executes the protocol honestly, individual measurements are never seen by any server in the clear. At the same time, VDAFs allow the servers to detect if a malicious or misconfigured client submitted an measurement that would result in an invalid aggregate result. |
| | Requirements for Scaling Deterministic Networks |
| |
|
Aiming at scaling deterministic networks, this document describes the technical and operational requirements when the network has large variation in latency among hops, great number of flows and/or multiple domains without the same time source. Different deterministic levels of applications co-exist and are transported in such a network. This document also describes the corresponding Deterministic Networking (DetNet) data plane enhancement requirements. |
| | Internationalization for the NFSv4 Protocols |
| |
|
This document describes the handling of internationalization for all NFSv4 protocols, including NFSv4.0, NFSv4.1, NFSv4.2 and extensions thereof, and future minor versions. It updates RFC7530 and RFC8881. |
| | Optimizing ACK mechanism for QUIC |
| |
|
The dependence on frequent acknowledgments (ACKs) is an artifact of current transport protocol designs rather than a fundamental requirement. This document analyzes the problems caused by contentions and collisions on the wireless medium between data packets and ACKs in WLAN and it proposes an ACK mechanism that minimizes the intensity of ACK Frame in QUIC, improving the performance of transport layer connection. |
| | Generalized Arguments of SRv6 Segment |
| |
|
This document analyzes the challenges of Arguments of SRv6 SID, and the chance of using Arguments of SRv6 SID to reduce the length of the IPv6 extension header. According to these analysis, this document specifies a kind of generalized and structured Arguments for SRv6 SID, which can carry multiple Arguments parts for a SRv6 SID. |
| | A Domain Name System (DNS) Service Parameter and Resource Record for Tunneling Information |
| |
|
A Domain Name System (DNS) Service Binding (SVCB) Service Parameter Type and a DNS Resource Record (RR) Type are specified for storing connection tunneling / encapsulation Information in the DNS. |
| | Simple Random Candidate Selection |
| |
|
This document describes a process to randomly select a subset of named candidates from a larger set of candidates. The process uses an unpredictable value that can be trusted by all candidates. This draft has a GitHub repository (https://github.com/paulehoffman/ draft-hoffman-random-candidate-selection). Issues and pull requests can be made there. |
| |
|
| |
| | RTP Payload Format for sub-codestream latency JPEG 2000 streaming |
| |
|
This RTP payload format defines the streaming of a video signal encoded as a sequence of JPEG 2000 codestreams. The format allows sub-codestream latency, such that the first RTP packet for a given codestream can be emitted before the entire codestream is available. |
| | A Concise Binary Object Representation (CBOR) of DNS Messages |
| |
| | draft-lenders-dns-cbor-06.txt |
| | Date: |
17/11/2023 |
| | Authors: |
Martine Lenders, Carsten Bormann, Thomas Schmidt, Matthias Waehlisch |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a compressed data format of DNS messages using the Concise Binary Object Representation [RFC8949]. The primary purpose is to keep DNS messages small in constrained networks. |
| | UMR application in Ethernet VPN(EVPN) |
| |
|
This document describes an application scenario that how unknown MAC- route(UMR) is used in the EVPN network. In particular, this document describes how MAC address route and UMR route are advertised on DC's GW or NVE. This document also describes the soloution that MAC mobility issue due to the lack of advertisement of specific MAC routes. However, some incremental work is required, which will be covered in a separate document. |
| | Identity Trust System |
| |
|
This document describes the identity trust system, which is an open identity authentication system that does not require federation of authentication domains. It is based on a symmetric authentication protocol and a specific infrastructure to ensure trust in the identity providers (IdPs). Regarding the main components: 1. Symmetric authentication protocol - Both entities MUST recognize each other and are authenticated by their identity provider according to a symmetric scheme. This protocol builds on and extends the OAuth Authorization Framework RFC6749. 2. Trustees' network - A special network, dedicated to creating a protected environment for exchanging authentication messages between IdPs, constitutes the infrastructure to avoid domain federation. 3. Custodian concept - IdPs are divided into two typologies to better protect personal data. A generic IdP (called trustee) for pure digital authentication and a specific IdP (called custodian) under the control of the country's authority with legal right to the individual's real data to ensure physical identity. |
| | QUIC Accurate ECN Acknowledgements |
| |
|
QUIC defines a variant of the ACK frame that carries cumulative count for each of the three ECN codepoints (ECT(1), ECT(0) and CE). From this information, the recipient of the ACK frame cannot deduce which ECN marking the individual packets were received with. This document defines an alternative ACK frame that encodes enough information to indicate which ECN mark each individual packet was received with. |
| | More Accurate Explicit Congestion Notification (ECN) Feedback in TCP |
| |
|
Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets instead of dropping them to indicate incipient congestion to the endpoints. Receivers with an ECN-capable transport protocol feed back this information to the sender. ECN was originally specified for TCP in such a way that only one feedback signal can be transmitted per Round-Trip Time (RTT). Recent new TCP mechanisms like Congestion Exposure (ConEx), Data Center TCP (DCTCP) or Low Latency, Low Loss, and Scalable Throughput (L4S) need more accurate ECN feedback information whenever more than one marking is received in one RTT. This document updates the original ECN specification in RFC 3168 to specify a scheme that provides more than one feedback signal per RTT in the TCP header. Given TCP header space is scarce, it allocates a reserved header bit previously assigned to the ECN-Nonce. It also overloads the two existing ECN flags in the TCP header. The resulting extra space is exploited to feed back the IP-ECN field received during the 3-way handshake as well. Supplementary feedback information can optionally be provided in two new TCP option alternatives, which are never used on the TCP SYN. The document also specifies the treatment of this updated TCP wire protocol by middleboxes. |
| |
|
| |
| | AC-Aware Bundling Service Interface in EVPN |
| |
|
An EVPN (Ethernet VPNs) provides an extensible and flexible multihoming VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and End Devices that can be physical or virtual. EVPN multihoming with Integrated Routing and Bridging (IRB) is one of the common deployment scenarios. Some deployments requires the capability to have multiple subnets designated with multiple VLAN IDs in the single broadcast domain. EVPN technology defines three different types of service interface which serve different requirements but none of them address the requirement of supporting multiple subnets within a single broadcast domain. In this document, we define a new service interface type to support multiple subnets in the single broadcast domain. Service interface proposed in this document will be applicable to multihoming cases only. |
| | Cookies: HTTP State Management Mechanism |
| |
|
This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265. |
| | Open Ethics Transparency Protocol |
| |
|
The Open Ethics Transparency Protocol (OETP) is an application-level protocol for publishing and accessing ethical Disclosures of IT Products and their Components. The Protocol is based on HTTP exchange of information about the ethical "postures", provided in an open and standardized format. The scope of the Protocol covers Disclosures for systems such as Software as a Service (SaaS) Applications, Software Applications, Software Components, Application Programming Interfaces (API), Automated Decision-Making (ADM) systems, and systems using Artificial Intelligence (AI). OETP aims to bring more transparent, predictable, and safe environments for the end-users. The OETP Disclosure Format is an extensible JSON-based format. |
| | The Use Cases for Secure Routing Path |
| |
|
Current routing mechanism is based on the shortest path, which only take the link status and the path accessibility into consideration, without the security and trustworthiness of links and forwarding nodes. As security has become an important factor to the user. This paper proposes to add security factor in the routing process. With the frequent occurrence of security incidents, services security is an essential demand for the users. As there are many security devices in the ISP's network, this draft proposes secure routing mechanism. The purpose of secure routing is to converge security and routing to ensure the secure data transmission. The scope is transmission process security, while end-to-end security and application layer security are out of scope. |
| | EPP Pre-Registration Verification |
| |
|
This Internet Draft introduces an extension to the Extensible Provisioning Protocol (EPP) for top-level domain (TLD) registries, enabling registrars to submit pre-registration information for domain names. The extension facilitates quality verification by the registry, employing advanced Artificial Intelligence and Machine Learning (AI/ML) techniques. Pre-registrations are assigned a quality score based on the analysis of the submitted data, ranging from 0 for non-abusive registrations to 100 for potentially abusive ones. This extension addresses the critical need to proactively identify and mitigate abusive domain registrations within TLDs, contributing to a safer and more reliable internet environment. The document outlines the EPP command definitions, XML schemas, data flow, and security considerations necessary to implement this innovative quality assurance mechanism, thereby enhancing the integrity and trustworthiness of TLD registrations. |
| |
|
| |
| | A Connectivity Monitoring Metric for IPPM |
| |
|
Within a Segment Routing domain, segment routed measurement packets can be sent along pre-determined paths. This enables new kinds of measurements. Connectivity monitoring allows to supervise the state and performance of a connection or a (sub)path from one or a few central monitoring systems. This document specifies a suitable type-P connectivity monitoring metric. |
| | Short-Lived Certificates for Secure Telephone Identity |
| |
|
When certificates are used as credentials to attest the assignment of ownership of telephone numbers, some mechanism is required to provide certificate freshness. This document specifies short-lived certificates as a means of guaranteeing certificate freshness for secure telephone identity (STIR), potentially relying on the Automated Certificate Management Environment (ACME) or similar mechanisms to allow signers to acquire certificates as needed. |
| | BFD in Demand Mode over a Point-to-Point MPLS LSP |
| |
|
This document describes procedures for using Bidirectional Forwarding Detection (BFD) in Demand mode to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-point Label Switched Paths. |
| | Generic Metric for the AIGP attribute |
| |
| | draft-ssangli-idr-bgp-generic-metric-aigp-07.txt |
| | Date: |
09/11/2023 |
| | Authors: |
Srihari Sangli, Shraddha Hegde, Reshma Das, Bruno Decraene, Bin Wen, Marcin Kozak, Jie Dong, Luay Jalil, Ketan Talaulikar |
| | Working Group: |
Individual Submissions (none) |
|
This document defines extensions to the AIGP attribute to carry Generic Metric sub-types. This is applicable when multiple domains exchange BGP routing information. The extension will aid in intent- based end-to-end path selection. |
| | A solution to the Hierarchical Route Reflector issue in RT Constraints |
| |
|
Route Target Constraints (RTC) is used to build a VPN route distribution graph such that routers only receive VPN routes corresponding to specified route-targets (RT) that they are interested in. This is done by exchanging the route-targets as routes in the RTC address-family and a corresponding "RT filter" is installed that influences the VPN route advertisement. In networks employing hierarchical Route Reflectors (RR) the use of RTC can lead to incorrect VPN route distribution and loss in connectivity as detailed in an earlier draft . Two solutions were provided to overcome the problem. This draft presents a method with suggested modifications to the RTC RFC in order to solve the hierarchical RR RTC problem in an efficient manner. |
| | The qpack_static_table_version TLS extension |
| |
|
This document specifies a new "qpack_static_table_version" TLS extension to enable clients and servers to agree upon the version of the HTTP/3 QPACK Static Table to use for communications between them. It also defines a new IANA registry to be used for documenting and publishing the entries in the QPACK static table. |
| | Usage specification of the otpauth URI format for TOTP and HOTP token generators |
| |
|
This document describes a foundational schema for the otpauth URI, utilized by TOTP (and/or HOTP) based authenticators. |
| | Explicit QUIC Path-ID extension |
| |
|
The work on QUIC multipath has almost converged, but we are still debating how to identify paths. The draft multipath version 06 identifies paths explicitly using the sequence number of the Connection Identifier used for sending packets on the path. The WG is considering an alternate proposal in which the path ID is explicit. In order to compare the two solutions, we propose here an extension to the multipath draft allowing endpoints to negotiate the use of explicit sequence numbers. When the extension is negotiated, endpoints announce new connection identifiers using a new MP_CONNECTION_ID frame, which carries the parameters of the NEW_CONNECTION_ID plus a path ID. This path ID is used instead of the CID sequence number to identify packet number spaces, to create encryption nonces, to identify paths in MP_ACK, MP_ABANDON, MP_AVAILABLE and MP_STANBY frames, and to perform the logic associated with path creation, path CID rotation, and NAT rebinding. The draft analyzes the pros and cons of using this extension. After experimentation and analysis, we expect that this extension will be either absorbed into a new version of the QUIc multipath draft, or abandoned. |
| | Architecture and Requirements for Transport Services |
| |
| | draft-ietf-taps-arch-19.txt |
| | Date: |
09/11/2023 |
| | Authors: |
Tommy Pauly, Brian Trammell, Anna Brunstrom, Gorry Fairhurst, Colin Perkins |
| | Working Group: |
Transport Services (taps) |
|
This document describes an architecture for exposing transport protocol features to applications for network communication. This system exposes transport protocol features to applications for network communication. The Transport Services Application Programming Interface (API) is based on an asynchronous, event-driven interaction pattern. This API uses messages for representing data transfer to applications, and describes how a Transport Services Implementation can use multiple IP addresses, multiple protocols, and multiple paths, and provide multiple application streams. This document provides the architecture and requirements. It defines common terminology and concepts to be used in definitions of a Transport Service API and a Transport Services Implementation. |
| |
|
| |
| | OAuth 2.0 Web Message Response Mode |
| |
|
This specification defines a new response mode for RFC6749 that uses HTML5 Web Messaging (a.k.a window.postMessage()) instead of the redirect for the Authorization Response from the Authorization Endpoint. It defines two modes: simple mode and relay mode. Relay mode can be used to protect the access token in the implicit grant case by confining it within the origins of authorization server or resource server and preventing it from being read by the client. |
| | SRPM Path Consistency over SRv6 |
| |
|
TWAMP can be used to measure the performance of end-to-end paths in networks. STAMP [rfc8762] and TWAMP light are more lightweight measurement methods. In the SRv6 network, it is also necessary to measure the performance of SRv6 policy. This document describes a method to measure srv6 policy through stamp and TWAMP light. |
| | NRP ID in SRv6 segment |
| |
|
This document proposes a method to carry the NRP-ID with the packet in the SRv6 segment. |
| | BFD Path Consistency over SR |
| |
|
Bidirectional Forwarding Detection (BFD) can be used to monitor paths between nodes. U-BFD defined in [I-D.ietf-bfd-unaffiliated-echo] can effectively reduce the device equipment. Seamless BFD (S-BFD) provides a simplified mechanism which is suitable for monitoring of paths that are setup dynamically and on a large scale network. In SR network, BFD can also be used to monitor SR paths. When a headend use BFD to monitor the segment list/CPath of SR Policy, the forward path of control packet is indicated by segment list, the reverse path of response control packet is via the shortest path from the reflector back to the initiator (headend) as determined by routing. The forward path and reverse path of control packet are likely inconsistent going through different intermediate nodes or links. This document describes a method to keep the forward path and reverse path consistent when using S-BFD or U-BFD to detect SR Policy |
| | Purge Originator Identification for OSPF |
| |
|
In RFC6232(Purge Originator Identification TLV for IS-IS), ISIS POI (Purge Originator Identification) TLV is added to the purge LSP to record the system ID of the IS generating it. At present, OSPF purge does not contain any information identifying the Router that generates the purge. This makes it difficult to locate the source router. While OSPF protocol is difficult to add additional content to the purge LSA, this document proposes generating a POI LSA together with a purge LSA to record the router ID of the router generating the purge. To address this issue, this document defines a POI LSA to record the router ID of the OSPF generating it. |
| | QUIC-enabled Service Differentiation for Traffic Engineering |
| |
| | draft-zmlk-quic-te-01.txt |
| | Date: |
08/11/2023 |
| | Authors: |
Zhilong Zheng, Yunfei Ma, Yanmei Liu, Mirja Kuehlewind |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a method for supporting QUIC-enabled service differentiation for traffic engineering through multipath and QUIC connection identifier (CID) encoding. This approach enables end-host networking stacks and applications to select packet routing paths in a wide area network (WAN), potentially improving end-to-end performance, cost, and reliability. The proposed method can be used in conjunction with segment-routing traffic engineering technologies, such as SRv6 TE. |
| | BIER Loop Avoidance using Segment Routing |
| |
| | draft-liu-bier-uloop-03.txt |
| | Date: |
08/11/2023 |
| | Authors: |
Yisong Liu, Changwang Lin, Zheng Zhang, Yuanxiang Qiu |
| | Working Group: |
Individual Submissions (none) |
|
This document provides a mechanism leveraging SR-MPLS and/or SRv6 to ensure that BIER messages can be forwarded loop-freeness during the IGP reconvergence process following a link-state change event. |
| | Online Certificate Status Protocol (OCSP) Nonce Extension |
| |
|
This document updates the Nonce extension section of RFC-8954. Nonce extension is a optional extension for Online Certificate Status Protocol (OCSP) request and response messages. OCSP is used for checking the status of a certificate, and the Nonce extension is used to cryptographically bind an OCSP response message to a particular OCSP request message. This document updates RFC 8954. |
| | Common Ancestor Objective Function and Parent Set DAG Metric Container Extension |
| |
| | draft-ietf-roll-nsa-extension-12.txt |
| | Date: |
08/11/2023 |
| | Authors: |
Remous-Aris Koutsiamanis, Georgios Papadopoulos, Nicolas Montavont, Pascal Thubert |
| | Working Group: |
Routing Over Low power and Lossy networks (roll) |
|
High reliability and low jitter can be achieved by being able to send data packets through multiple paths, via different parents, in a network. This document details how to exchange the necessary information within RPL control packets to let a node better select the different parents that will be used to forward a packet over different paths. This document also describes the Objective Function which takes advantage of this information to implement multi-path routing. |
| | Controlling Secure Network Enrollment in RPL networks |
| |
| | draft-ietf-roll-enrollment-priority-10.txt |
| | Date: |
08/11/2023 |
| | Authors: |
Michael Richardson, Rahul Jadhav, Pascal Thubert, Huimin She, Konrad Iwanicki |
| | Working Group: |
Routing Over Low power and Lossy networks (roll) |
|
[RFC9032] defines a method by which a potential [RFC9031] enrollment proxy can announce itself as available for new Pledges to enroll on a network. The announcement includes a priority for enrollment. This document provides a mechanism by which a RPL DODAG Root can globally disable enrollment announcements or adjust the base priority for enrollment operations. |
| | SF Aware TE Topology YANG Model |
| |
| | draft-ietf-teas-sf-aware-topo-model-12.txt |
| | Date: |
08/11/2023 |
| | Authors: |
Igor Bryskin, Xufeng Liu, Young Lee, Jim Guichard, Luis Contreras, Daniele Ceccarelli, Jeff Tantsura, Dmytro Shytyi |
| | Working Group: |
Traffic Engineering Architecture and Signaling (teas) |
|
This document describes a YANG data model for TE network topologies that are network service and function aware. |
| |
|
| |
| | RTP Payload Format for SFrame |
| |
|
This document describes the RTP payload format of SFrame. |
| | Multiple Algorithm Rules in DNSSEC |
| |
|
This document restates the requirements on DNSSEC signing and validation and makes small adjustments in order to allow for more flexible handling of configurations that advertise multiple Secure Entry Points (SEP) with different signing algorithms via their DS record or trust anchor set. The adjusted rules allow both for multi- signer operation and for the transfer of signed DNS zones between providers, where the providers support disjoint DNSSEC algorithm sets. In addition, the proposal enables pre-publication of a trust anchor in preparation for an algorithm rollover, such as of the root zone. This document updates RFCs 4035, 6840, and 8624. |
| | Deprecating Insecure Practices in RADIUS |
| |
|
RADIUS crypto-agility was first mandated as future work by RFC 6421. The outcome of that work was the publication of RADIUS over TLS (RFC 6614) and RADIUS over DTLS (RFC 7360) as experimental documents. Those transport protocols have been in wide-spread use for many years in a wide range of networks. They have proven their utility as replacements for the previous UDP (RFC 2865) and TCP (RFC 6613) transports. With that knowledge, the continued use of insecure transports for RADIUS has serious and negative implications for privacy and security. This document formally deprecates using the User Datagram Protocol (UDP) and of the Transmission Control Protocol (TCP) as transport protocols for RADIUS. These transports are permitted inside of secure networks, but their use in those networks is still discouraged. For all other environments, the use of secure transports such as IPsec or TLS is mandated. We also discuss additional security issues with RADIUS deployments, and give recommendations for practices which increase security and privacy. |
| | Reverse CoA in RADIUS |
| |
|
This document defines a "reverse change of authorization (CoA)" path for RADIUS packets. This specification allows a home server to send CoA packets in "reverse" down a RADIUS/TLS connection. Without this capability, it is impossible for a home server to send CoA packets to a NAS which is behind a firewall or NAT gateway. The reverse CoA functionality extends the available transport methods for CoA packets, but it does not change anything else about how CoA packets are handled. |
| | A Profile for Autonomous System Provider Authorization |
| |
| | draft-ietf-sidrops-aspa-profile-17.txt |
| | Date: |
07/11/2023 |
| | Authors: |
Alexander Azimov, Eugene Uskov, Randy Bush, Job Snijders, Russ Housley, Ben Maddison |
| | Working Group: |
SIDR Operations (sidrops) |
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Provider Authorization (ASPA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASPA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other Autonomous Systems (ASes) as its upstream providers. When validated, an ASPA's eContent can be used for detection and mitigation of route leaks. |
| |
|
| |
| | Join Proxy for Bootstrapping of Constrained Network Elements |
| |
|
This document extends the work of Bootstrapping Remote Secure Key Infrastructures (BRSKI) by replacing the Circuit-proxy between Pledge and Registrar by a stateless/stateful constrained Join Proxy. The constrained Join Proxy is a mesh neighbor of the Pledge and can relay a DTLS session originating from a Pledge with only link-local addresses to a Registrar which is not a mesh neighbor of the Pledge. This document defines a protocol to securely assign a Pledge to a domain, represented by a Registrar, using an intermediary node between Pledge and Registrar. This intermediary node is known as a "constrained Join Proxy". An enrolled Pledge can act as a constrained Join Proxy. |
| | Multicast and Ethernet VPN with Segment Routing P2MP and Ingress Replication |
| |
| | draft-ietf-bess-mvpn-evpn-sr-p2mp-08.txt |
| | Date: |
06/11/2023 |
| | Authors: |
Rishabh Parekh, Clarence Filsfils, Arvind Venkateswaran, Hooman Bidgoli, Dan Voyer, Zhaohui Zhang |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain carries traffic from a Root to a set of Leaves. This document describes extensions to BGP encodings and procedures for P2MP trees and Ingress Replication used in BGP/MPLS IP VPNs and Ethernet VPNs in a Segment Routing domain. |
| | IPv4-Only and IPv6-Only PE Design DESIGN ALL SAFI |
| |
| | draft-ietf-bess-v4-v6-pe-all-safi-00.txt |
| | Date: |
06/11/2023 |
| | Authors: |
Gyan Mishra, Mankamana Mishra, Jeff Tantsura, Sudha Madhavi, Qing Yang, Adam Simpson, Shuanglong Chen |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
As Enterprises and Service Providers upgrade their brown field or green field MPLS/SR core to an IPv6 transport, Multiprotocol BGP (MP- BGP)now plays an important role in the transition of their Provider (P) core network as well as Provider Edge (PE) Inter-AS peering network from IPv4 to IPv6. Operators must have flexiblity to continue to support IPv4 customers when both the Core and Edge networks migrate to IPv6. As well as must be able to support IPv6 networks in cases where operators decide to remain on an IPv4 network or during transition. This document details the External BGP (eBGP) PE-PE Inter-AS and PE- CE Edge peering IPv4-Only PE design where both IPv4 and IPv6 all supported SAFI NLRI can be advertised over a single IPv4 peer and IPv6-Only PE Design where all supported SAFI NLRI can be advertised over a single IPv6 peer. This document also defines a new IPv4 BGP next hop encoding standard that uses an IPv4 address as the next hop and not an IPv4 mapped IPv6 address. This document also provides vendor specific test cases for the IPv4-Only peering design and IPv6-Only PE design as well as test results for the five major vendors stakeholders in the routing and switching indusrty, Cisco, Juniper, Arista, Nokia and Huawei. With the test results provided for the IPv6-Only Edge peering design, the goal is that all other vendors around the world that have not been tested will begin to adopt and implement the design. |
| | LISP L2/L3 EID Mobility Using a Unified Control Plane |
| |
| | draft-ietf-lisp-eid-mobility-13.txt |
| | Date: |
06/11/2023 |
| | Authors: |
Marc Portoles-Comeras, Vrushali Ashtaputre, Fabio Maino, Victor Moreno, Dino Farinacci |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
The LISP control plane offers the flexibility to support multiple overlay flavors simultaneously. This document specifies how LISP can be used to provide control-plane support to deploy a unified L2 and L3 overlay solution for End-point Identifier (EID) mobility, as well as analyzing possible deployment options and models. |
| | The ARK Identifier Scheme |
| |
| | draft-kunze-ark-38.txt |
| | Date: |
06/11/2023 |
| | Authors: |
John Kunze, Emmanuelle Bermes |
| | Working Group: |
Individual Submissions (none) |
|
The ARK (Archival Resource Key) naming scheme is designed to facilitate the high-quality and persistent identification of information objects. The label "ark:" marks the start of a core ARK identifier that can be made actionable by prepending the beginning of a URL. Meant to be usable after today's networking technologies become obsolete, that core should be recognizable in the future as a globally unique ARK independent of the URL hostname, HTTP, etc. A founding principle of ARKs is that persistence is purely a matter of service and neither inherent in an object nor conferred on it by a particular naming syntax. The best any identifier can do is lead users to services that support robust reference. A full-functioning ARK leads the user to the identified object and, with the "?info" inflection appended, returns a metadata record and a commitment statement that is both human- and machine-readable. Tools exist for minting, binding, and resolving ARKs. Responsibility for this Document The ARK Alliance Technical Working Group [ARKAtech] is responsible for the content of this Internet Draft. The group homepage lists monthly meeting notes and agendas starting from March 2019. Revisions of the spec are maintained on github at [ARKdrafts]. |
| | Multi-Site Solution for Ethernet VPN (EVPN) Overlay |
| |
|
This document describes the procedures for interconnecting two or more Network Virtualization Overlays (NVOs) with EVPN via NVO over IP-only network. The solution interconnects Ethernet VPN network by using NVO with Ethernet VPN (EVPN) to facilitate the interconnect in a scalable fashion. The motivation is to support extension of Layer-2 and Layer-3, Unicast & Multicast, VPNs without having to rely on typical Data Center Interconnect (DCI) technologies like MPLS/ VPLS. The requirements for the interconnect are similar to the ones specified in [RFC7209], "Requirements for Ethernet VPN (EVPN)". In particular, this document describes the difference of the Gateways (GWs) procedure and combined functionality from [RFC9014], "Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks" and and [I-D.ietf-bess-evpn-ipvpn-interworking], "EVPN Interworking with IPVPN", which this solution is interoperable to. This document updates and replaces all previous version of Multi-site EVPN based VXLAN using Border Gateways (draft- sharma-multi-site-evpn). |
| | A Simple Control Protocol for MPLS SFLs |
| |
|
In RFC 8957 the concept of MPLS synonymos flow labels (SFL) was introduced. This document describes a simple control protocol that runs over an associated control header to request, withdraw, and extend the lifetime of such labels. It is not the only control protocol that might be used to support SFL, but it has the benefit of being able to be used without modification of the existing MPLS control protocols. The existence of this design is not intended to restrict the ability to enhance an existing MPLS control protocol to add a similar capability. |
| | Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description |
| |
|
This document provides the External Data Representation Standard (XDR) description for Network File System version 4 (NFSv4) minor version 1. It obsoletes and replaces RFC5662. |
| | MIMI Delivery Service |
| |
|
This document describes the MIMI Delivery Service. |
| | DNS-Based Multicast Stream Discovery |
| |
|
This document describes an application of DNS-SD for the advertisement and discovery of multicast streams. This is especially useful with multicast streams that use a dynamically-assigned multicast address. |
| | Mobile Subscription Info in DHCP and Router Advertisement |
| |
|
In some environments where a mobile client joins a network via simple DHCP process and/or IPv6 Router Advertisement, the serving network may want to know the mobile client's mobile subscription information. This is particularly useful when a mobile client switches to a private Wi-Fi network such as home network which uses simple SSID/ Pre-Shared-Key combination. The network can use the mobile subscription information to identify the client's serving mobile network and provide service continuity. |
| | Reliability Framework for SRv6 Service Function Chaining |
| |
|
This document describes the framework for protection of service function chains in source routing networks. |
| | BGP Flow Specification Extensions for Path Scheduling |
| |
|
Path scheduling is required in many network scenarios. For example, some links or nodes will be shut down in the tidal network when the traffic decreases, which may lead to the expiration of some routing paths. This document defines a new type of component for BGP Flow Specification to identify the packets arrived at different time slot. Based on that, the headend can steer packets into different paths at different time. |
| | Referencing big external files in email messages |
| |
|
This document specifies a way to reference big attachments in email messages without including them inline. |
| | Using HTTP/3 Stream Limits in HTTP/2 |
| |
|
A variant mechanism for managing stream limits is described for HTTP/2. This scheme is based on that used in QUIC and is more robust against certain patterns of abuse. |
| | Updates to Dynamic IPv6 Multicast Address Group IDs |
| |
|
Describes limitations of the existing range of dynamic IPv6 multicast addresses specified in RFC3307. Recommends replacing these allocations with a new registry in the IPv6 Multicast Address Space Registry registry group. Suggests initial contents of the new registry: a reduced allocation for MADCAP (RFC2730) and solicited- node multicast addresses (which were not previously noted in RFC3307). |
| | Use of Internationalized Email Addresses in the Extensible Provisioning Protocol (EPP) |
| |
|
This document describes an EPP command-response extension that permits usage of Internationalized Email Addresses in the EPP protocol and specifies the terms when it can be used by EPP clients and servers. The Extensible Provisioning Protocol (EPP), being developed before the standards for SMTPUTF8 compliant addresses, does not support such email addresses. TO BE REMOVED on turning to RFC: The document is edited in the dedicated github repo (https://github.com/beldmit/eppeai). Please send your submissions via GitHub. |
| | Distribute SRv6 Locator by DHCP |
| |
|
In a SRv6 network, each SRv6 Segment Endpoint Node must be assigned a locator, and segment IDs are generated within the address space of this locator. This document describes a method for assigning locators to SRv6 Segment Endpoint Nodes through DHCPv6. |
| | Trusted Execution Environment Provisioning (TEEP) Protocol |
| |
| | draft-ietf-teep-protocol-18.txt |
| | Date: |
06/11/2023 |
| | Authors: |
Hannes Tschofenig, Mingliang Pei, David Wheeler, Dave Thaler, Akira Tsukamoto |
| | Working Group: |
Trusted Execution Environment Provisioning (teep) |
|
This document specifies a protocol that installs, updates, and deletes Trusted Components in a device with a Trusted Execution Environment (TEE). This specification defines an interoperable protocol for managing the lifecycle of Trusted Components. |
| | Universally Unique IDentifiers (UUID) |
| |
|
This specification defines the UUIDs (Universally Unique IDentifiers) and the UUID Uniform Resource Name (URN) namespace. UUIDs are also known as GUIDs (Globally Unique IDentifiers). A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation's (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. This document obsoletes RFC4122. |
| |
|
| |
| | Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer |
| |
|
This document describes Path Maximum Transmission Unit Discovery (PMTUD) in Bit Indexed Explicit Replication (BIER) layer. |
| | Simple Two-way Active Measurement Protocol (STAMP) Data Model |
| |
|
This document specifies the data model for implementations of Session-Sender and Session-Reflector for Simple Two-way Active Measurement Protocol (STAMP) mode using YANG. |
| | BGP Extensions for the Mobile User Plane (MUP) SAFI |
| |
| | draft-mpmz-bess-mup-safi-03.txt |
| | Date: |
05/11/2023 |
| | Authors: |
Tetsuya Murakami, Keyur Patel, Satoru Matsushima, Zhaohui Zhang, Swadesh Agrawal, Dan Voyer |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a new SAFI known as a BGP Mobile User Plane (BGP-MUP) SAFI to support MUP Extensions and a extended community for BGP. This document also provides BGP signaling and procedures for the new SAFI to convert mobile session information into appropriate IP forwarding information. These extensions can be used by operators between a PE, and a Controller for integrating mobile user plane into BGP MUP network using the IP based routing. |
| | SCION Overview |
| |
|
The Internet has been successful beyond even the most optimistic expectations and is intertwined with many aspects of our society. But although the world-wide communication system guarantees global reachability, the Internet has not primarily been built with security and high availability in mind. The next-generation inter-network architecture SCION (Scalability, Control, and Isolation On Next- generation networks) aims to address these issues. SCION was explicitly designed from the outset to offer security and availability by default. The architecture provides route control, failure isolation, and trust information for end-to-end communication. It also enables multi-path routing between hosts. This document discusses the motivations behind the SCION architecture and gives a high-level overview of its fundamental components, including its authentication model and the setup of the control- and data plane. As SCION is already in production use today, the document concludes with an overview of SCION deployments. For detailed descriptions of SCION's components, refer to [I-D.dekater-scion-pki], [I-D.dekater-scion-controlplane], and [I-D.dekater-scion-dataplane]. A more detailed analysis of relationships and dependencies between components is available in [I-D.rustignoli-scion-components]. |
| | SRv6 Upper-Layer Checksum |
| |
|
This document defines SRH C-flag and its processing, which makes the IPv6 upper-layer checksum computation rule applicable to both compressed and uncompressed SRv6 SIDs. |
| | Interoperable Private Identity Discovery for E2EE Messaging |
| |
|
This document specifies how users can privately discover each other's Service Specific Identifiers (SSIs) when using end-to-end encrypted messaging services across multiple providers. Users can retrieve SSIs without revealing their social graphs to service providers they are not delivering messages through, using their phone numbers, email, user IDs, or other Service Independent Identifiers (SIIs). Our specification can be based on private information retrieval or associative private sets membership schemes, both of which provide reasonable tradeoffs between privacy and cost. |
| | Domain Name System in Mostly Isolated Networks |
| |
|
This document lists operational methods to enable local DNS name resolving on an isolated network, where that target network may have intermittent reachability to Internet and/or have very long delays, disabling the real-time query and response flow to the authoritative name servers on Internet. |
| | A Usable Formal Methods Sample Problem from TEEP |
| |
|
This draft follows the invitation of [I-D.farrell-ufmrg-sample] to propose another sample problem for demonstration, training, and evaluation of formal methods in IETF work. It draws on recent work from the Software Updates for the Internet of Things [suit] and Trusted Execution Environment Provisioning [teep] working groups to define a sample modeling problem for a novel rather than a familiar IETF protocol. |
| | Zero-Configuration Assignment of IPv6 Multicast Addresses |
| |
|
Describes a zero-configuration protocol for dynamically assigning IPv6 multicast addresses. Applications randomly assign multicast group IDs from a reserved range and prevent collisions by using mDNS to publish records in a new "eth-addr.arpa" special-use domain. This protocol satisfies all of the criteria listed in draft-ietf-pim- zeroconf-mcast-addr-alloc-ps. |
| | Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect |
| |
|
The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. RDAP allows a server to make access control decisions based on client identity, and as such it includes support for client identification features provided by the Hypertext Transfer Protocol (HTTP). Identification methods that require clients to obtain and manage credentials from every RDAP server operator present management challenges for both clients and servers, whereas a federated authentication system would make it easier to operate and use RDAP without the need to maintain server-specific client credentials. This document describes a federated authentication system for RDAP based on OpenID Connect. |
| |
|
| |
| | The Hypertext Transfer Protocol Attestable (HTTPA) Version 2 |
| |
|
The Hypertext Transfer Protocol Attestable version 2 (HTTPA/2) is an HTTP extension. It is a transaction-based protocol agnostic to Transport Layer Security (TLS) in which the Trusted Execution Environment (TEE) is considered a new type of requested resource over the Internet. The original Hypertext Transfer Protocol Attestable (HTTPA) (referred to as HTTPA/1 in the rest of the document) includes remote attestation (RA) process onto the HTTPS protocol in the assumption of using Transport Layer Security (TLS) across the Internet. In contrast, the design of HTTPA/2 could establish a trusted (attested) and more secure communication without dependence on TLS. The definition of Attestation for the purposes of this draft: The process of vouching for the accuracy of TEE based services, configuration, and data where the TEE conveys Evidence about its environment, roots of trust and protected functions. The Evidence is a digital expression of TEE trustworthiness. |
| | Batched Signatures |
| |
|
This document proposes a construction for batch signatures where a single, potentially expensive, "base" digital signature authenticates a Merkle tree constructed from many messages. Discussion of this work is encouraged to happen on the IETF TLSWG mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/PhDJsandboxaq/draft-joseph-batch- signatures |
| | TurboTLS for faster connection establishment |
| |
| | draft-joseph-tls-turbotls-00.txt |
| | Date: |
04/11/2023 |
| | Authors: |
Douglas Stebila, David Joseph, Carlos Aguilar-Melchor, Jason Goertzen |
| | Working Group: |
Individual Submissions (none) |
|
This document provides a high level protocol description for handshaking over UDP in the Transport Layer Security (TLS) protocol (version independent). In parallel, a TCP session is established, and once this is done, the TLS session reverts to TCP. In the event that the UDP handshaking portion fails, TurboTLS falls back to TLS- over-TCP as is usually done, resulting in negligible latency cost in the case of failure. Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/PhDJsandboxaq/draft-ietf-turbotls- design/. |
| | Generic Protocol Extension for VXLAN (VXLAN-GPE) |
| |
|
This document describes extending Virtual eXtensible Local Area Network (VXLAN), via changes to the VXLAN header, with four new capabilities: support for multi-protocol encapsulation, support for operations, administration and maintenance (OAM) signaling, support for ingress-replicated BUM Traffic (i.e. Broadcast, Unknown unicast, or Multicast), and explicit versioning. New protocol capabilities can be introduced via shim headers. |
| | PCEP Extensions for BIER-TE |
| |
| | draft-ietf-pce-bier-te-00.txt |
| | Date: |
04/11/2023 |
| | Authors: |
Ran Chen, Zheng Zhang, Huaimo Chen, Senthil Dhanaraj, Fengwei Qin, Aijun Wang |
| | Working Group: |
Path Computation Element (pce) |
|
Bit Index Explicit Replication (BIER)-TE shares architecture and packet formats with BIER as described in [RFC8279]. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies as described in [RFC9262]. BIER-TE Path can be derived from a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a PCE to compute and initiate the path for the BIER-TE. |