| |
| RFC 5201 | Host Identity Protocol |
| |
| Authors: | R. Moskowitz, P. Nikander, P. Jokela, Ed., T. Henderson. |
| Date: | April 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7401 |
| Updated by: | RFC 6253 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5201 |
|
This memo specifies the details of the Host Identity Protocol (HIP).HIP allows consenting hosts to securely establish and maintain sharedIP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Sigma-compliant Diffie-Hellman key exchange, using public key identifiers from a new HostIdentity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the- middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper- layer protocols, such as TCP and UDP. |
|
| |
| RFC 5202 | Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) |
| |
| Authors: | P. Jokela, R. Moskowitz, P. Nikander. |
| Date: | April 2008 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7402 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5202 |
|
This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with theHost Identity Protocol (HIP). |
|
| |
| RFC 5203 | Host Identity Protocol (HIP) Registration Extension |
| |
| Authors: | J. Laganier, T. Koponen, L. Eggert. |
| Date: | April 2008 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8003 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5203 |
|
This document specifies a registration mechanism for the HostIdentity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. |
|
| |
| RFC 5204 | Host Identity Protocol (HIP) Rendezvous Extension |
| |
|
|
This document defines a rendezvous extension for the Host IdentityProtocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile. |
|
| |
| RFC 5205 | Host Identity Protocol (HIP) Domain Name System (DNS) Extensions |
| |
| Authors: | P. Nikander, J. Laganier. |
| Date: | April 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8005 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5205 |
|
This document specifies a new resource record (RR) for the DomainName System (DNS), and how to use it with the Host Identity Protocol(HIP). This RR allows a HIP node to store in the DNS its HostIdentity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs). |
|
| |
| RFC 5206 | End-Host Mobility and Multihoming with the Host Identity Protocol |
| |
| Authors: | P. Nikander, T. Henderson, Ed., C. Vogt, J. Arkko. |
| Date: | April 2008 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8046 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5206 |
|
This document defines mobility and multihoming extensions to the HostIdentity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study. |
|
| |
| RFC 5207 | NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication |
| |
| Authors: | M. Stiemerling, J. Quittek, L. Eggert. |
| Date: | April 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5207 |
|
The Host Identity Protocol (HIP) changes the way in which twoInternet hosts communicate. One key advantage over other schemes is that HIP does not require modifications to the traditional network- layer functionality of the Internet, i.e., its routers. In the current Internet, however, many devices other than routers modify the traditional network-layer behavior of the Internet. These"middleboxes" are intermediary devices that perform functions other than the standard functions of an IP router on the datagram path between source and destination hosts. Whereas some types of middleboxes may not interfere with HIP at all, others can affect some aspects of HIP communication, and others can render HIP communication impossible. This document discusses the problems associated with HIP communication across network paths that include specific types of middleboxes, namely, network address translators and firewalls. It identifies and discusses issues in the current HIP specifications that affect communication across these types of middleboxes. This document is a product of the IRTF HIP Research Group. |
|
| |
| RFC 5208 | Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2 |
| |
|
|
This document represents a republication of PKCS #8 v1.2 from RSALaboratories' Public Key Cryptography Standard (PKCS) series. Change control is transferred to the IETF. The body of this document, except for the security considerations section, is taken directly from the PKCS #8 v1.2 specification.
This document describes a syntax for private-key information. |
|
| |
| RFC 5209 | Network Endpoint Assessment (NEA): Overview and Requirements |
| |
| Authors: | P. Sangster, H. Khosravi, M. Mani, K. Narayan, J. Tardo. |
| Date: | June 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5209 |
|
This document defines the problem statement, scope, and protocol requirements between the components of the NEA (Network EndpointAssessment) reference model. NEA provides owners of networks (e.g., an enterprise offering remote access) a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance-oriented decisions. The posture information is frequently useful for detecting systems that are lacking or have out-of-date security protection mechanisms such as: anti-virus and host-based firewall software. In order to provide context for the requirements, a reference model and terminology are introduced. |
|
| |
| RFC 5210 | A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience |
| |
| Authors: | J. Wu, J. Bi, X. Li, G. Ren, K. Xu, M. Williams. |
| Date: | June 2008 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5210 |
|
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. In an effort to enhance the Internet withIP source address validation, a prototype implementation of the IPSource Address Validation Architecture (SAVA) was created and an evaluation was conducted on an IPv6 network. This document reports on the prototype implementation and the test results, as well as the lessons and insights gained from experimentation. |
|
| |
| RFC 5211 | An Internet Transition Plan |
| |
| Authors: | J. Curran. |
| Date: | July 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5211 |
|
This memo provides one possible plan for transitioning the Internet from a predominantly IPv4-based connectivity model to a predominantlyIPv6-based connectivity model. |
|
| |
| RFC 5212 | Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) |
| |
| Authors: | K. Shiomoto, D. Papadimitriou, JL. Le Roux, M. Vigoureux, D. Brungard. |
| Date: | July 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5212 |
|
Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extendingMPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi-layered network of either a single switching technology or multiple switching technologies.
In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a multi-region network (MRN). When referring in general to a layered network, which may consist of either single or multiple regions, this document uses the term multi-layer network (MLN). This document defines a framework for GMPLS based multi-region / multi- layer networks and lists a set of functional requirements. |
|
| |
| RFC 5213 | Proxy Mobile IPv6 |
| |
| Authors: | S. Gundavelli, Ed., K. Leung, V. Devarapalli, K. Chowdhury, B. Patil. |
| Date: | August 2008 |
| Formats: | txt json html |
| Updated by: | RFC 6543, RFC 7864 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5213 |
|
Network-based mobility management enables IP mobility for a host without requiring its participation in any mobility-related signaling. The network is responsible for managing IP mobility on behalf of the host. The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signaling on its behalf. This specification describes a network-based mobility management protocol and is referred to as Proxy Mobile IPv6. |
|
| |
| RFC 5214 | Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) |
| |
| Authors: | F. Templin, T. Gleeson, D. Thaler. |
| Date: | March 2008 |
| Formats: | txt html json |
| Obsoletes: | RFC 4214 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5214 |
|
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects dual-stack (IPv6/IPv4) nodes over IPv4 networks. ISATAP views theIPv4 network as a link layer for IPv6 and supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access(NBMA) model. |
|
| |
| RFC 5215 | RTP Payload Format for Vorbis Encoded Audio |
| |
| Authors: | L. Barbato. |
| Date: | August 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5215 |
|
This document describes an RTP payload format for transporting Vorbis encoded audio. It details the RTP encapsulation mechanism for rawVorbis data and the delivery mechanisms for the decoder probability model (referred to as a codebook), as well as other setup information.
Also included within this memo are media type registrations and the details necessary for the use of Vorbis with the Session DescriptionProtocol (SDP). |
|
| |
| RFC 5216 | The EAP-TLS Authentication Protocol |
| |
|
|
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. TransportLayer Security (TLS) provides for mutual authentication, integrity- protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation.
This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. |
|
| |
| RFC 5217 | Memorandum for Multi-Domain Public Key Infrastructure Interoperability |
| |
| Authors: | M. Shimaoka, Ed., N. Hastings, R. Nielsen. |
| Date: | July 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5217 |
|
The objective of this document is to establish a terminology framework and to suggest the operational requirements of Public KeyInfrastructure (PKI) domain for interoperability of multi-domainPublic Key Infrastructure, where each PKI domain is operated under a distinct policy. This document describes the relationships betweenCertification Authorities (CAs), provides the definition and requirements for PKI domains, and discusses typical models of multi- domain PKI. |
|
| |
| RFC 5218 | What Makes for a Successful Protocol? |
| |
| Authors: | D. Thaler, B. Aboba. |
| Date: | July 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5218 |
|
The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success.Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success. It is hoped that these observations can serve as guidance for future protocol work. |
|
| |
| RFC 5219 | A More Loss-Tolerant RTP Payload Format for MP3 Audio |
| |
|
|
This document describes an RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layerIII audio (commonly known as "MP3"). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. This document obsoletes RFC 3119, correcting typographical errors in the "SDP usage" section and pseudo-code appendices. |
|
| |
| RFC 5220 | Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules |
| |
| Authors: | A. Matsumoto, T. Fujisaki, R. Hiromi, K. Kanayama. |
| Date: | July 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5220 |
|
A single physical link can have multiple prefixes assigned to it. In that environment, end hosts might have multiple IP addresses and be required to use them selectively. RFC 3484 defines default source and destination address selection rules and is implemented in a variety of OSs. But, it has been too difficult to use operationally for several reasons. In some environments where multiple prefixes are assigned on a single physical link, the host using the default address selection rules will experience some trouble in communication. This document describes the possible problems that end hosts could encounter in an environment with multiple prefixes. |
|
| |
| RFC 5221 | Requirements for Address Selection Mechanisms |
| |
| Authors: | A. Matsumoto, T. Fujisaki, R. Hiromi, K. Kanayama. |
| Date: | July 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5221 |
|
There are some problematic cases when using the default address selection mechanism that RFC 3484 defines. This document describes additional requirements that operate with RFC 3484 to solve the problems. |
|
| |
| RFC 5222 | LoST: A Location-to-Service Translation Protocol |
| |
|
|
This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. |
|
| |
| RFC 5223 | Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP) |
| |
| Authors: | H. Schulzrinne, J. Polk, H. Tschofenig. |
| Date: | August 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5223 |
|
The Location-to-Service Translation (LoST) Protocol describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform ResourceLocators (URLs). LoST servers can be located anywhere, but a placement closer to the end host, e.g., in the access network, is desirable. In disaster situations with intermittent network connectivity, such a LoST server placement provides benefits regarding the resiliency of emergency service communication.
This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). |
|
| |
| RFC 5224 | Diameter Policy Processing Application |
| |
| Authors: | M. Brenner. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5224 |
|
This document describes the need for a new IANA Diameter Command Code to be used in a vendor-specific new application for invocation ofPolicy Processing (Policy Evaluation, or Evaluation and Enforcement).This application is needed as one of the implementations of the OpenMobile Alliance (OMA) Policy Evaluation, Enforcement and Management(PEEM) enabler, namely for the PEM-1 interface used to send a request/response for Policy Processing. |
|
| |
| RFC 5225 | RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite |
| |
| Authors: | G. Pelletier, K. Sandlund. |
| Date: | April 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5225 |
|
This document specifies ROHC (Robust Header Compression) profiles that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol,User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (UserDatagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP(Encapsulating Security Payload) headers.
This specification defines a second version of the profiles found inRFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but does not obsolete them.
The ROHCv2 profiles introduce a number of simplifications to the rules and algorithms that govern the behavior of the compression endpoints. It also defines robustness mechanisms that may be used by a compressor implementation to increase the probability of decompression success when packets can be lost and/or reordered on the ROHC channel. Finally, the ROHCv2 profiles define their own specific set of header formats, using the ROHC formal notation. |
|
| |
| RFC 5226 | Guidelines for Writing an IANA Considerations Section in RFCs |
| |
|
|
Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned NumbersAuthority (IANA).
In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. IfIANA is expected to play a role in the management of a namespace,IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.
This document obsoletes RFC 2434. |
|
| |
| RFC 5227 | IPv4 Address Conflict Detection |
| |
|
|
When two hosts on the same link attempt to use the same IPv4 address at the same time (except in rare special cases where this has been arranged by prior coordination), problems ensue for one or both hosts. This document describes (i) a simple precaution that a host can take in advance to help prevent this misconfiguration from happening, and (ii) if this misconfiguration does occur, a simple mechanism by which a host can passively detect, after the fact, that it has happened, so that the host or administrator may respond to rectify the problem. |
|
| |
| RFC 5228 | Sieve: An Email Filtering Language |
| |
|
|
This document describes a language for filtering email messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black boxInternet Message Access Protocol (IMAP) servers, as the base language has no variables, loops, or ability to shell out to external programs. |
|
| |
| RFC 5229 | Sieve Email Filtering: Variables Extension |
| |
|
|
In advanced mail filtering rule sets, it is useful to keep state or configuration details across rules. This document updates the Sieve filtering language (RFC 5228) with an extension to support variables.The extension changes the interpretation of strings, adds an action to store data in variables, and supplies a new test so that the value of a string can be examined. |
|
| |
| RFC 5230 | Sieve Email Filtering: Vacation Extension |
| |
| Authors: | T. Showalter, N. Freed, Ed.. |
| Date: | January 2008 |
| Formats: | txt html json |
| Updated by: | RFC 8580 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5230 |
|
This document describes an extension to the Sieve email filtering language for an autoresponder similar to that of the Unix "vacation" command for replying to messages. Various safety features are included to prevent problems such as message loops. |
|
| |
| RFC 5231 | Sieve Email Filtering: Relational Extension |
| |
| Authors: | W. Segmuller, B. Leiba. |
| Date: | January 2008 |
| Formats: | txt html json |
| Obsoletes: | RFC 3431 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5231 |
|
This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators.In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields.
This document obsoletes RFC 3431. |
|
| |
| RFC 5232 | Sieve Email Filtering: Imap4flags Extension |
| |
| Authors: | A. Melnikov. |
| Date: | January 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5232 |
|
Recent discussions have shown that it is desirable to set differentIMAP (RFC 3501) flags on message delivery. This can be done, for example, by a Sieve interpreter that works as a part of a MailDelivery Agent.
This document describes an extension to the Sieve mail filtering language for setting IMAP flags. The extension allows setting of both IMAP system flags and IMAP keywords. |
|
| |
| RFC 5233 | Sieve Email Filtering: Subaddress Extension |
| |
|
|
On email systems that allow for 'subaddressing' or 'detailed addressing' (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses.This document defines an extension to the Sieve Email FilteringLanguage that allows users to compare against the user and detail sub-parts of an address. |
|
| |
| RFC 5234 | Augmented BNF for Syntax Specifications: ABNF |
| |
|
|
Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form(BNF), called Augmented BNF (ABNF), has been popular among manyInternet specifications. The current specification documents ABNF.It balances compactness and simplicity with reasonable representational power. The differences between standard BNF andABNF involve naming rules, repetition, alternatives, order- independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. |
|
| |
| RFC 5235 | Sieve Email Filtering: Spamtest and Virustest Extensions |
| |
|
|
The Sieve email filtering language "spamtest", "spamtestplus", and"virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric "scores". It is the responsibility of the underlying Sieve implementation to do the actual checks that result in proper input to the tests. |
|
| |
| RFC 5236 | Improved Packet Reordering Metrics |
| |
| Authors: | A. Jayasumana, N. Piratla, T. Banka, A. Bare, R. Whitner. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5236 |
|
This document presents two improved metrics for packet reordering, namely, Reorder Density (RD) and Reorder Buffer-occupancy Density(RBD). A threshold is used to clearly define when a packet is considered lost, to bound computational complexity at O(N), and to keep the memory requirement for evaluation independent of N, where N is the length of the packet sequence. RD is a comprehensive metric that captures the characteristics of reordering, while RBD evaluates the sequences from the point of view of recovery from reordering.
These metrics are simple to compute yet comprehensive in their characterization of packet reordering. The measures are robust and orthogonal to packet loss and duplication. |
|
| |
| RFC 5237 | IANA Allocation Guidelines for the Protocol Field |
| |
|
|
This document revises the IANA guidelines for allocating new Protocol field values in IPv4 header. It modifies the rules specified in RFC2780 by removing the Expert Review option. The change will also affect the allocation of Next Header field values in IPv6. |
|
| |
| RFC 5238 | Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) |
| |
|
|
This document specifies the use of Datagram Transport Layer Security(DTLS) over the Datagram Congestion Control Protocol (DCCP). DTLS provides communications privacy for applications that use datagram transport protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. DCCP is a transport protocol that provides a congestion-controlled unreliable datagram service. |
|
| |
| RFC 5239 | A Framework for Centralized Conferencing |
| |
| Authors: | M. Barnes, C. Boulton, O. Levin. |
| Date: | June 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5239 |
|
This document defines the framework for Centralized Conferencing.The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber, Q.931 or ISDN User Part(ISUP), to exchange media in a centralized unicast conference. TheCentralized Conferencing Framework defines logical entities and naming conventions. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems. |
|
| |
| RFC 5240 | Protocol Independent Multicast (PIM) Bootstrap Router MIB |
| |
| Authors: | B. Joshi, R. Bijlani. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5240 |
|
This document defines a portion of the Management Information Base(MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Bootstrap Router (BSR) mechanism for PIM (ProtocolIndependent Multicast). |
|
| |
| RFC 5241 | Naming Rights in IETF Protocols |
| |
| Authors: | A. Falk, S. Bradner. |
| Date: | 1 April 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5241 |
|
This document proposes a new revenue source for the IETF to support standardization activities: protocol field naming rights, i.e., the association of commercial brands with protocol fields. This memo describes a process for assignment of rights and explores some of the issues associated with the process. Individuals or organizations that wish to purchase naming rights for one or more protocol fields are expected to follow this process. |
|
| |
| RFC 5242 | A Generalized Unified Character Code: Western European and CJK Sections |
| |
| Authors: | J. Klensin, H. Alvestrand. |
| Date: | 1 April 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5242 |
|
Many issues have been identified with the use of general-purpose character sets for internationalized domain names and similar purposes. This memo describes a fully unified coded character set for scripts based on Latin, Greek, Cyrillic, and Chinese (CJK) characters. It is not a complete specification of that character set. |
|
| |
| RFC 5243 | OSPF Database Exchange Summary List Optimization |
| |
|
|
This document describes a backward-compatible optimization for theDatabase Exchange process in OSPFv2 and OSPFv3. In this optimization, a router does not list a Link State Advertisement (LSA) in Database Description packets sent to a neighbor, if the same or a more recent instance of the LSA was listed in a Database Description packet already received from the neighbor. This optimization reducesDatabase Description overhead by about 50% in large networks. This optimization does not affect synchronization, since it only omits unnecessary information from Database Description packets. |
|
| |
| RFC 5244 | Definition of Events for Channel-Oriented Telephony Signalling |
| |
| Authors: | H. Schulzrinne, T. Taylor. |
| Date: | June 2008 |
| Formats: | txt json html |
| Updates: | RFC 4733 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5244 |
|
This memo updates RFC 4733 to add event codes for telephony signals used for channel-associated signalling when carried in the telephony event RTP payload. It supersedes and adds to the original assignment of event codes for this purpose in Section 3.14 of RFC 2833. As documented in Appendix A of RFC 4733, some of the RFC 2833 events have been deprecated because their specification was ambiguous, erroneous, or redundant. In fact, the degree of change from Section3.14 of RFC 2833 is such that implementations of the present document will be fully backward compatible with RFC 2833 implementations only in the case of full ABCD-bit signalling. This document expands and improves the coverage of signalling systems compared to RFC 2833. |
|
| |
| RFC 5245 | Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols |
| |
|
|
This document describes a protocol for Network Address Translator(NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called InteractiveConnectivity Establishment (ICE). ICE makes use of the SessionTraversal Utilities for NAT (STUN) protocol and its extension,Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session InitiationProtocol (SIP). |
|
| |
| RFC 5246 | The Transport Layer Security (TLS) Protocol Version 1.2 |
| |
| Authors: | T. Dierks, E. Rescorla. |
| Date: | August 2008 |
| Formats: | txt html json |
| Obsoletes: | RFC 3268, RFC 4346, RFC 4366 |
| Obsoleted by: | RFC 8446 |
| Updates: | RFC 4492 |
| Updated by: | RFC 5746, RFC 5878, RFC 6176, RFC 7465, RFC 7507, RFC 7568, RFC 7627, RFC 7685, RFC 7905, RFC 7919, RFC 8447, RFC 9155 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5246 |
|
This document specifies Version 1.2 of the Transport Layer Security(TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. |
|
| |
| RFC 5247 | Extensible Authentication Protocol (EAP) Key Management Framework |
| |
|
|
The Extensible Authentication Protocol (EAP), defined in RFC 3748, enables extensible network access authentication. This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated byEAP authentication algorithms, known as "methods". It also provides a detailed system-level security analysis, describing the conditions under which the key management guidelines described in RFC 4962 can be satisfied. |
|
| |
| RFC 5248 | A Registry for SMTP Enhanced Mail System Status Codes |
| |
|
|
The specification for enhanced mail system status codes, RFC 3463, establishes a new code model and lists a collection of status codes.While it anticipated that more codes would be added over time, it did not provide an explicit mechanism for registering and tracking those codes. This document specifies an IANA registry for mail system enhanced status codes, and initializes that registry with the codes so far established in published standards-track documents, as well as other codes that have become established in the industry. |
|
| |
| RFC 5249 | Templates for Internet-Drafts Containing MIB Modules |
| |
|
|
This memo references three annotated templates for IETF documents that contain the definition of MIB modules. It is intended to reduce the work of the editors of such documents, making these documents more uniform and easier to read and review, thus furthering the quality of such documents and expediting their publication. |
|
| |
| RFC 5250 | The OSPF Opaque LSA Option |
| |
| Authors: | L. Berger, I. Bryskin, A. Zinin, R. Coltun. |
| Date: | July 2008 |
| Formats: | txt json html |
| Obsoletes: | RFC 2370 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5250 |
|
This document defines enhancements to the OSPF protocol to support a new class of link state advertisements (LSAs) called Opaque LSAs.Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. Opaque LSAs consist of a standard LSA header followed by application-specific information. The information field may be used directly by OSPF or by other applications. Standard OSPF link-state database flooding mechanisms are used to distribute OpaqueLSAs to all or some limited portion of the OSPF topology.
This document replaces RFC 2370 and adds to it a mechanism to enable an OSPF router to validate Autonomous System (AS)-scope Opaque LSAs originated outside of the router's OSPF area. |
|
| |
| RFC 5251 | Layer 1 VPN Basic Mode |
| |
| Authors: | D. Fedyk, Ed., Y. Rekhter, Ed., D. Papadimitriou, R. Rabbat, L. Berger. |
| Date: | July 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5251 |
|
This document describes the Basic Mode of Layer 1 VPNs (L1VPNs).L1VPN Basic Mode (L1VPN BM) is a port-based VPN. In L1VPN BasicMode, the basic unit of service is a Label Switched Path (LSP) between a pair of customer ports within a given VPN port topology.This document defines the operational model using either provisioning or a VPN auto-discovery mechanism, and the signaling extensions for the L1VPN BM. |
|
| |
| RFC 5252 | OSPF-Based Layer 1 VPN Auto-Discovery |
| |
| Authors: | I. Bryskin, L. Berger. |
| Date: | July 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5252 |
|
This document defines an Open Shortest Path First (OSPF) based Layer1 Virtual Private Network (L1VPN) auto-discovery mechanism. This mechanism enables provider edge (PE) devices using OSPF to dynamically learn about the existence of each other, and attributes of configured customer edge (CE) links and their associations withL1VPNs. This document builds on the L1VPN framework and requirements and provides a L1VPN basic mode auto-discovery mechanism. |
|
| |
| RFC 5253 | Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode |
| |
| Authors: | T. Takeda, Ed.. |
| Date: | July 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5253 |
|
This document provides an applicability statement on the use ofGeneralized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to support Basic Mode Layer 1 Virtual Private Networks(L1VPNs).
L1VPNs provide customer services and connectivity at Layer 1 overLayer 1 networks. The operation of L1VPNs is divided into the BasicMode and the Enhanced Mode, where the Basic Mode of operation does not feature any exchange of routing information between the Layer 1 network and the customer domain. This document examines how GMPLS protocols can be used to satisfy the requirements of a Basic ModeL1VPN. |
|
| |
| RFC 5254 | Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) |
| |
| Authors: | N. Bitar, Ed., M. Bocci, Ed., L. Martini, Ed.. |
| Date: | October 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5254 |
|
This document describes the necessary requirements to allow a service provider to extend the reach of pseudowires across multiple domains.These domains can be autonomous systems under one provider administrative control, IGP areas in one autonomous system, different autonomous systems under the administrative control of two or more service providers, or administratively established pseudowire domains. |
|
| |
| RFC 5255 | Internet Message Access Protocol Internationalization |
| |
| Authors: | C. Newman, A. Gulbrandsen, A. Melnikov. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5255 |
|
Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings. It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME).This specification defines a collection of IMAP extensions that improve international support including language negotiation for international error text, translations for namespace prefixes, and comparator negotiation for search, sort, and thread. |
|
| |
| RFC 5256 | Internet Message Access Protocol - SORT and THREAD Extensions |
| |
| Authors: | M. Crispin, K. Murchison. |
| Date: | June 2008 |
| Formats: | txt html json |
| Updated by: | RFC 5957 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5256 |
|
This document describes the base-level server-based sorting and threading extensions to the IMAP protocol. These extensions provide substantial performance improvements for IMAP clients that offer sorted and threaded views. |
|
| |
| RFC 5257 | Internet Message Access Protocol - ANNOTATE Extension |
| |
| Authors: | C. Daboo, R. Gellens. |
| Date: | June 2008 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5257 |
|
The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain "meta data" for messages, or individual message parts, stored in a mailbox on the server. For example, this can be used to attach comments and other useful information to a message. It is also possible to attach annotations to specific parts of a message, so that, for example, they could be marked as seen, or important, or a comment added.
Note that this document was the product of a WG that had good consensus on how to approach the problem. Nevertheless, the WG felt it did not have enough information on implementation and deployment hurdles to meet all of the requirements of a Proposed Standard. TheIETF solicits implementations and implementation reports in order to make further progress.
Implementers should be aware that this specification may change in an incompatible manner when going to Proposed Standard status. However, any incompatible changes will result in a new capability name being used to prevent problems with any deployments of the experimental extension. |
|
| |
| RFC 5258 | Internet Message Access Protocol version 4 - LIST Command Extensions |
| |
| Authors: | B. Leiba, A. Melnikov. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5258 |
|
IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions, such as Mailbox Referrals, that have required specialized lists we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. |
|
| |
| RFC 5259 | Internet Message Access Protocol - CONVERT Extension |
| |
| Authors: | A. Melnikov, Ed., P. Coates, Ed.. |
| Date: | July 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5259 |
|
CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences, or on server settings. |
|
| |
| RFC 5260 | Sieve Email Filtering: Date and Index Extensions |
| |
| Authors: | N. Freed. |
| Date: | July 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5260 |
|
This document describes the "date" and "index" extensions to theSieve email filtering language. The "date" extension gives Sieve the ability to test date and time values in various ways. The "index" extension provides a means to limit header and address tests to specific instances of header fields when header fields are repeated. |
|
| |
| RFC 5261 | An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors |
| |
| Authors: | J. Urpalainen. |
| Date: | September 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5261 |
|
Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. In order to send changes to an XML document, an entire copy of the new version must be sent, unless there is a means of indicating only the portions that have changed. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document.In addition to them, with basic <add&rt;, <replace&rt;, and <remove&rt; directives a set of patches can then be applied to update an existingXML document. |
|
| |
| RFC 5262 | Presence Information Data Format (PIDF) Extension for Partial Presence |
| |
| Authors: | M. Lonnfors, E. Leppanen, H. Khartabil, J. Urpalainen. |
| Date: | September 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5262 |
|
The Presence Information Document Format (PIDF) specifies the baseline XML-based format for describing presence information. One of the characteristics of the PIDF is that the document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist, it is often beneficial to limit the amount of transported information over the network. This document introduces a new MIME type that enables transporting of either only the changed parts or the full PIDF-based presence information. |
|
| |
| RFC 5263 | Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information |
| |
| Authors: | M. Lonnfors, J. Costa-Requena, E. Leppanen, H. Khartabil. |
| Date: | September 2008 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5263 |
|
By default, presence delivered using the presence event package for the Session Initiation Protocol (SIP) is represented in the PresenceInformation Data Format (PIDF). A PIDF document contains a set of elements, each representing a different aspect of the presence being reported. When any subset of the elements change, even just a single element, a new document containing the full set of elements is delivered. This memo defines an extension allowing delivery of only the presence data that has actually changed. |
|
| |
| RFC 5264 | Publication of Partial Presence Information |
| |
| Authors: | A. Niemi, M. Lonnfors, E. Leppanen. |
| Date: | September 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5264 |
|
The Session Initiation Protocol (SIP) Extension for Event StatePublication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent. Using thePresence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update. As a consequence, updating a sizeable presence document with small changes bears a considerable overhead and is therefore inefficient. Especially with low bandwidth and high latency links, this can constitute a considerable burden to the system. This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for publication of partial presence information. |
|
| |
| RFC 5265 | Mobile IPv4 Traversal across IPsec-Based VPN Gateways |
| |
| Authors: | S. Vaarala, E. Klovning. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5265 |
|
This document outlines a solution for the Mobile IPv4 (MIPv4) andIPsec coexistence problem for enterprise users. The solution consists of an applicability statement for using Mobile IPv4 andIPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely. |
|
| |
| RFC 5266 | Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE) |
| |
| Authors: | V. Devarapalli, P. Eronen. |
| Date: | June 2008 |
| Formats: | txt html json |
| Also: | BCP 0136 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 5266 |
|
Enterprise users require mobility and secure connectivity when they roam and connect to the services offered in the enterprise. Secure connectivity is required when the user connects to the enterprise from an untrusted network. Mobility is beneficial when the user moves, either inside or outside the enterprise network, and acquires a new IP address. This document describes a solution using MobileIPv4 (MIPv4) and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility. |
|
| |
| RFC 5267 | Contexts for IMAP4 |
| |
|
|
The IMAP4rev1 protocol has powerful search facilities as part of the core protocol, but lacks the ability to create live, updated results that can be easily handled. This memo provides such an extension, and shows how it can be used to provide a facility similar to virtual mailboxes. |
|
| |
| RFC 5268 | Mobile IPv6 Fast Handovers |
| |
|
|
Mobile IPv6 enables a Mobile Node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This"handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care-of Address configuration, andBinding Update, is often unacceptable to real-time traffic such asVoice over IP (VoIP). Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. |
|
| |
| RFC 5269 | Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND) |
| |
| Authors: | J. Kempf, R. Koodli. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5269 |
|
Fast Mobile IPv6 requires that a Fast Binding Update is secured using a security association shared between an Access Router and a MobileNode in order to avoid certain attacks. In this document, a method for provisioning a shared key from the Access Router to the MobileNode is defined to protect this signaling. The Mobile Node generates a public/private key pair using the same public key algorithm as forSEND (RFC 3971). The Mobile Node sends the public key to the AccessRouter. The Access Router encrypts a shared handover key using the public key and sends it back to the Mobile Node. The Mobile Node decrypts the shared handover key using the matching private key, and the handover key is then available for generating an authenticator on a Fast Binding Update. The Mobile Node and Access Router use theRouter Solicitation for Proxy Advertisement and Proxy RouterAdvertisement from Fast Mobile IPv6 for the key exchange. The key exchange messages are required to have SEND security; that is, the source address is a Cryptographically Generated Address (CGA) and the messages are signed using the CGA private key of the sending node.This allows the Access Router, prior to providing the shared handover key, to verify the authorization of the Mobile Node to claim the address so that the previous care-of CGA in the Fast Binding Update can act as the name of the key. |
|
| |
| RFC 5270 | Mobile IPv6 Fast Handovers over IEEE 802.16e Networks |
| |
| Authors: | H. Jang, J. Jee, Y. Han, S. Park, J. Cha. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5270 |
|
This document describes how a Mobile IPv6 Fast Handover can be implemented on link layers conforming to the IEEE 802.16e suite of specifications. The proposed scheme tries to achieve seamless handover by exploiting the link-layer handover indicators and thereby synchronizing the IEEE 802.16e handover procedures with the MobileIPv6 fast handover procedures efficiently. |
|
| |
| RFC 5271 | Mobile IPv6 Fast Handovers for 3G CDMA Networks |
| |
| Authors: | H. Yokota, G. Dommety. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5271 |
|
Mobile IPv6 is designed to maintain its connectivity while moving from one network to another. It is adopted in 3G CDMA networks as a way to maintain connectivity when the mobile node (MN) moves between access routers. However, this handover procedure requires not only movement detection by the MN, but also the acquisition of a newCare-of Address and Mobile IPv6 registration with the new care-of address before the traffic can be sent or received in the target network. During this period, packets destined for the mobile node may be lost, which may not be acceptable for a real-time application such as Voice over IP (VoIP) or video telephony. This document specifies fast handover methods in the 3G CDMA networks in order to reduce latency and packet loss during handover. |
|
| |
| RFC 5272 | Certificate Management over CMS (CMC) |
| |
|
|
This document defines the base syntax for CMC, a CertificateManagement protocol using the Cryptographic Message Syntax (CMS).This protocol addresses two immediate needs within the InternetPublic Key Infrastructure (PKI) community:
1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key CryptographyStandard), and
2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.
CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. |
|
| |
| RFC 5273 | Certificate Management over CMS (CMC): Transport Protocols |
| |
|
|
This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic MessageSyntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP. |
|
| |
| RFC 5274 | Certificate Management Messages over CMS (CMC): Compliance Requirements |
| |
|
|
This document provides a set of compliance statements about the CMC(Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC. |
|
| |
| RFC 5275 | CMS Symmetric Key Management and Distribution |
| |
| Authors: | S. Turner. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5275 |
|
This document describes a mechanism to manage (i.e., set up, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanism uses theCryptographic Message Syntax (CMS) protocol and CertificateManagement over CMS (CMC) protocol to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support Secure/Multipurpose InternetMail Extensions (S/MIME) Mail List Agents (MLAs). |
|
| |
| RFC 5276 | Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records |
| |
| Authors: | C. Wallace. |
| Date: | August 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5276 |
|
The Server-based Certificate Validation Protocol (SCVP) defines an extensible means of delegating the development and validation of certification paths to a server. It can be used to support the development and validation of certification paths well after the expiration of the certificates in the path by specifying a time of interest in the past. The Evidence Record Syntax (ERS) defines structures, called evidence records, to support the non-repudiation of the existence of data. Evidence records can be used to preserve materials that comprise a certification path such that trust in the certificates can be established after the expiration of the certificates in the path and after the cryptographic algorithms used to sign the certificates in the path are no longer secure. This document describes usage of the SCVP WantBack feature to convey evidence records, enabling SCVP responders to provide preservation evidence for certificates and certificate revocation lists (CRLs). |
|
| |
| RFC 5277 | NETCONF Event Notifications |
| |
| Authors: | S. Chisholm, H. Trevino. |
| Date: | July 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5277 |
|
This document defines mechanisms that provide an asynchronous message notification delivery service for the Network Configuration protocol(NETCONF). This is an optional capability built on top of the baseNETCONF definition. This document defines the capabilities and operations necessary to support this service. |
|
| |
| RFC 5278 | IANA Registration of Enumservices for Voice and Video Messaging |
| |
| Authors: | J. Livingood, D. Troshynski. |
| Date: | July 2008 |
| Formats: | txt json html |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5278 |
|
This document registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice, video, and unified communications to a messaging system. This vmsg Enumservice registers three Enumservice types: "voicemsg", "videomsg", and"unifmsg". Each type also registers the subtypes "sip", "sips","http", and "https", as well as the subtype "tel" for the "voicemsg" type. |
|
| |
| RFC 5279 | A Uniform Resource Name (URN) Namespace for the 3rd Generation Partnership Project (3GPP) |
| |
| Authors: | A. Monrad, S. Loreto. |
| Date: | July 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5279 |
|
This document describes the Namespace Identifier (NID) for UniformResource Namespace (URN) resources published by the 3rd GenerationPartnership Project (3GPP). 3GPP defines and manages resources that utilize this URN name model. Management activities for these and other resource types are provided by the 3GPP Support Team. |
|
| |
| RFC 5280 | Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
| |
| Authors: | D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk. |
| Date: | May 2008 |
| Formats: | txt json html |
| Obsoletes: | RFC 3280, RFC 4325, RFC 4630 |
| Updated by: | RFC 6818, RFC 8398, RFC 8399, RFC 9549, RFC 9598, RFC 9608, RFC 9618 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5280 |
|
This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and twoInternet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. |
|
| |
| RFC 5281 | Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0) |
| |
|
|
EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase. During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase. During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks. The data phase may also be used for additional, arbitrary data exchange. |
|
| |
| RFC 5282 | Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol |
| |
|
|
An authenticated encryption algorithm combines encryption and integrity into a single operation; such algorithms may also be referred to as combined modes of an encryption cipher or as combined mode algorithms. This document describes the use of authenticated encryption algorithms with the Encrypted Payload of the Internet KeyExchange version 2 (IKEv2) protocol.
The use of two specific authenticated encryption algorithms with theIKEv2 Encrypted Payload is also described; these two algorithms are the Advanced Encryption Standard (AES) in Galois/Counter Mode (AESGCM) and AES in Counter with CBC-MAC Mode (AES CCM). Additional documents may describe the use of other authenticated encryption algorithms with the IKEv2 Encrypted Payload. |
|
| |
| RFC 5283 | LDP Extension for Inter-Area Label Switched Paths (LSPs) |
| |
| Authors: | B. Decraene, JL. Le Roux, I. Minei. |
| Date: | July 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5283 |
|
To facilitate the establishment of Label Switched Paths (LSPs) that would span multiple IGP areas in a given Autonomous System (AS), this document describes a new optional Longest-Match Label MappingProcedure for the Label Distribution Protocol (LDP).
This procedure allows the use of a label if the ForwardingEquivalence Class (FEC) Element matches an entry in the RoutingInformation Base (RIB). Matching is defined by an IP longest-match search and does not mandate an exact match. |
|
| |
| RFC 5284 | User-Defined Errors for RSVP |
| |
| Authors: | G. Swallow, A. Farrel. |
| Date: | August 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5284 |
|
The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object for communicating errors. That object has a defined format that permits the definition of 256 error codes. As RSVP has been developed and extended, the convention has been to be conservative in defining new error codes. Further, no provision for user-defined errors exists in RSVP.
This document defines a USER_ERROR_SPEC to be used in addition to theERROR_SPEC to carry additional user information related to errors. |
|
| |
| RFC 5285 | A General Mechanism for RTP Header Extensions |
| |
| Authors: | D. Singer, H. Desineni. |
| Date: | July 2008 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8285 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5285 |
|
This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in eachRTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. |
|
| |
| RFC 5286 | Basic Specification for IP Fast Reroute: Loop-Free Alternates |
| |
| Authors: | A. Atlas, Ed., A. Zinin, Ed.. |
| Date: | September 2008 |
| Formats: | txt html json |
| Updated by: | RFC 8518 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5286 |
|
This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes.This simple approach does not require any support from other routers.The extent to which this goal can be met by this specification is dependent on the topology of the network. |
|
| |
| RFC 5287 | Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks |
| |
| Authors: | A. Vainshtein, Y(J). Stein. |
| Date: | August 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5287 |
|
This document defines extension to the Pseudowire Emulation Edge-to-Edge (PWE3) control protocol RFC 4447 and PWE3 IANA allocations RFC4446 required for the setup of Time-Division Multiplexing (TDM) pseudowires in MPLS networks. |
|
| |
| RFC 5288 | AES Galois Counter Mode (GCM) Cipher Suites for TLS |
| |
| Authors: | J. Salowey, A. Choudhury, D. McGrew. |
| Date: | August 2008 |
| Formats: | txt json html |
| Updated by: | RFC 9325 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5288 |
|
This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) authenticated encryption operation. GCM provides both confidentiality and data origin authentication, can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. This memo defines TLS cipher suites that use AES-GCM with RSA, DSA, andDiffie-Hellman-based key exchange mechanisms. |
|
| |
| RFC 5289 | TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM) |
| |
| Authors: | E. Rescorla. |
| Date: | August 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5289 |
|
RFC 4492 describes elliptic curve cipher suites for Transport LayerSecurity (TLS). However, all those cipher suites use HMAC-SHA-1 as their Message Authentication Code (MAC) algorithm. This document describes sixteen new cipher suites for TLS that specify stronger MAC algorithms. Eight use Hashed Message Authentication Code (HMAC) withSHA-256 or SHA-384, and eight use AES in Galois Counter Mode (GCM). |
|
| |
| RFC 5290 | Comments on the Usefulness of Simple Best-Effort Traffic |
| |
| Authors: | S. Floyd, M. Allman. |
| Date: | July 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5290 |
|
This document presents some observations on "simple best-effort traffic", defined loosely for the purposes of this document asInternet traffic that is not covered by Quality of Service (QOS) mechanisms, congestion-based pricing, cost-based fairness, admissions control, or the like. One observation is that simple best-effort traffic serves a useful role in the Internet, and is worth keeping.While differential treatment of traffic can clearly be useful, we believe such mechanisms are useful as *adjuncts* to simple best- effort traffic, not as *replacements* of simple best-effort traffic.A second observation is that for simple best-effort traffic, some form of rough flow-rate fairness is a useful goal for resource allocation, where "flow-rate fairness" is defined by the goal of equal flow rates for different flows over the same path. |
|
| |
| RFC 5291 | Outbound Route Filtering Capability for BGP-4 |
| |
| Authors: | E. Chen, Y. Rekhter. |
| Date: | August 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5291 |
|
This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of Outbound Route Filters (ORFs) that the peer would use to constrain/filter its outbound routing updates to the speaker. |
|
| |
| RFC 5292 | Address-Prefix-Based Outbound Route Filter for BGP-4 |
| |
| Authors: | E. Chen, S. Sangli. |
| Date: | August 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5292 |
|
This document defines a new Outbound Router Filter (ORF) type forBGP, termed "Address Prefix Outbound Route Filter", that can be used to perform address-prefix-based route filtering. This ORF-type supports prefix-length- or range-based matching, wild-card-based address prefix matching, as well as the exact address prefix matching for address families. |
|
| |
| RFC 5293 | Sieve Email Filtering: Editheader Extension |
| |
| Authors: | J. Degener, P. Guenther. |
| Date: | August 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5293 |
|
This document defines two new actions for the "Sieve" email filtering language that add and delete email header fields. |
|
| |
| RFC 5294 | Host Threats to Protocol Independent Multicast (PIM) |
| |
| Authors: | P. Savola, J. Lingard. |
| Date: | August 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5294 |
|
This memo complements the list of multicast infrastructure security threat analysis documents by describing Protocol IndependentMulticast (PIM) threats specific to router interfaces connecting hosts. |
|
| |
| RFC 5295 | Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK) |
| |
| Authors: | J. Salowey, L. Dondeti, V. Narayanan, M. Nakhjiri. |
| Date: | August 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5295 |
|
The Extensible Authentication Protocol (EAP) defined the ExtendedMaster Session Key (EMSK) generation, but reserved it for unspecified future uses. This memo reserves the EMSK for the sole purpose of deriving root keys. Root keys are master keys that can be used for multiple purposes, identified by usage definitions. This document also specifies a mechanism for avoiding conflicts between root keys by deriving them in a manner that guarantees cryptographic separation. Finally, this document also defines one such root key usage: Domain-Specific Root Keys are root keys made available to and used within specific key management domains. |
|
| |
| RFC 5296 | EAP Extensions for EAP Re-authentication Protocol (ERP) |
| |
| Authors: | V. Narayanan, L. Dondeti. |
| Date: | August 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6696 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5296 |
|
The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to not repeat the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting. |
|
| |
| RFC 5297 | Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES) |
| |
| Authors: | D. Harkins. |
| Date: | October 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5297 |
|
This memo describes SIV (Synthetic Initialization Vector), a block cipher mode of operation. SIV takes a key, a plaintext, and multiple variable-length octet strings that will be authenticated but not encrypted. It produces a ciphertext having the same length as the plaintext and a synthetic initialization vector. Depending on how it is used, SIV achieves either the goal of deterministic authenticated encryption or the goal of nonce-based, misuse-resistant authenticated encryption. |
|
| |
| RFC 5298 | Analysis of Inter-Domain Label Switched Path (LSP) Recovery |
| |
| Authors: | T. Takeda, Ed., A. Farrel, Ed., Y. Ikejiri, JP. Vasseur. |
| Date: | August 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5298 |
|
Protection and recovery are important features of service offerings in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and GMPLS networks are being extended from single domain scope to multi-domain environments.
Various schemes and processes have been developed to establish LabelSwitched Paths (LSPs) in multi-domain environments. These are discussed in RFC 4726: "A Framework for Inter-Domain MultiprotocolLabel Switching Traffic Engineering".
This document analyzes the application of these techniques to protection and recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse TrafficEngineering (TE) LSPs in multi-domain networks. |
|
