|
Internet Drafts - IDs for May/2009
Index - Month Index of IDs
All IDs - sorted by date)
30/05/2009
| |
|
| |
| | SASL Yet Another Password Mechanism |
| |
|
This document describes a password authentication mechanism, called YAP-SHA-256-TLS-UNIQ, for use in protocols which support Simple Authentication and Security Layer (SASL) framework. The mechanism relies on security services provided by a lower layer, such as Transport Layer Security (TLS), to protect the authentication exchange, and subsequent application data exchange, from common attacks. The YAP-SHA-256-TLS-UNIQ mechanism can be viewed as an alternative to other password-based SASL mechanism, such as PLAIN, CRAM-MD5, and DIGEST-MD5. |
29/05/2009
| |
|
| |
| | Definition of ACH TLV Structure |
| |
|
In some application of the associated channel header (ACH), it is necessary to have the ability to include a set of TLVs to provide additional context information for the ACH payload. This document defines a number of TLV types. NOTE the family of Address Types is known to be incomplete. The authors request that members of the MPLS-TP community provide details of their required address formats in the form of text for the creation of an additional sections similar to Section 3.1. NOTE other TLV types will be added in further revisions of this document. The authors request that members if the MPLS-TP community requiring new TLVs to complete there MPLS-TP specifications provide details of their required TLV in the form of text for the creation of additional sections similar to Section 2.2. |
28/05/2009
| |
|
| |
| | Initial Hypertext Transfer Protocol (HTTP) Method Registrations |
| |
|
This document registers those Hypertext Transfer Protocol (HTTP) methods which have been defined in standards-track RFCs before the IANA HTTP Method Registry was established. |
| | A Mixer Control Package for the Media Control Channel Framework |
| |
|
This document defines a Media Control Channel Framework Package for managing mixers for media conferences and connections. The package defines request elements for managing conference mixers, managing mixers between conferences and/or connections, as well as associated responses and notifications. The package also defines elements for auditing package capabilities and mixers. |
| | A Profile for AS Adjacency Attestation Objects |
| |
|
This document defines a standard profile for AS Adjacency Attestation Objects (AAOs). An AAO is a digitally signed object that provides a means of verifying that an AS has made an attestation that it has a inter-domain routing adjacency with one or more other AS's, with the associated inference that this AS may announce or receive routes with these adjacent AS's in the inter-domain domain environment. |
| | RFC 4648 Implementation Report |
| |
|
This is an implementation report of RFC4648, for the purpose of advancing the document to Draft Standard. See for more information. |
| | IPv6 RA-Guard |
| |
|
It is particularly easy to experience "rogue" routers on an unsecured link [reference4]. Devices acting as a rougue router may send illegitimate RAs. Section 6 of SeND [RFC3971] provides a full solution to this problem, by enabling routers certification. This solution does, however, require all nodes on an L2 network segment to support SeND, as well as it carries some deployment challenges. End- nodes must be provisioned with certificate anchors. The solution works better when end-nodes have access to a Certificate Revocation List server, and to a Network Time Protocol server, both typically off-link, which brings some bootstrap issues. When using IPv6 within a single L2 network segment it is possible and sometimes desirable to enable layer 2 devices to drop rogue RAs before they reach end-nodes. In order to distinguish valid from rogue RAs, the L2 devices can use a spectrum of criterias, from a static scheme that blocks RAs received on un-trusted ports, or from un-trusted sources, to a more dynamic scheme that uses SeND to challenge RA sources. This document reviews various techniques applicable on the L2 devices to reduce the threat of rogue RAs. |
27/05/2009
| |
|
| |
| | DRINKS Use cases and Protocol Requirements |
| |
|
This document captures the use cases and associated requirements for interfaces to provision session establishment data into SIP Service Provider components that aid with session routing. Specifically, the current version of this document focuses on the provisioning of one such element, termed the registry. |
| | An NETCONF- and NETMOD-based Architecture for Network Management |
| |
|
NETCONF gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content carried via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities. This document describes how NETCONF and YANG help build network management applications that meet the needs of network operators. |
| | Requirements for a Condition-based URI Selection (CBUS) using the Session Initiation Protocol (SIP) |
| |
|
This specification defines CBUS requirements for the SIP interface between the CBUS Client and the CBUS server, based on the requirements in OMA. |
| | An ABNF Extension for code generation |
| |
|
This document describes an ABNF extension for code generation. The extension has two features; extension rule and non-sequence group notations. The extension rules are used to direct the parser generator with things like data types, variable names, forced value for a variable, etc. The non-sequence group feature was proposed as part of RFC 2234 in the past, but dropped due to its ambiguities. The feature is proposed again in this document not as a fundamental building block, but as an add-on. The elements of a non-sequence group are unordered, and are allowed multiple appearance.We attempt to minimize the ambiguities stemmed from repetition of an element by defining specific repetition rules for elements of a non-sequence group and non-sequence group themselves. |
| | Transport Instance BGP |
| |
|
BGP4 protocol is a well established single standard of an inter- domain Internet routing and non Internet routing information distribution today. For many applications it is a lso the protocol of choice to disseminate various application based information intra- domain. It's popularity and it's wide use has been effectively provided by it's reliable transport, session protection as well as loop free build in mechanism. It has been observed in both intra-domain as well as inter-domain applications that reliable information distribution is an extremely desired tool for many services. Introduction of Multiprotocol Extensions to BGP even further attracted various sorts of new information to be carried over BGP4. The observation proves that amount and nature of information carried by BGP increases and diverges from the original goal of interconnection for IP Internet Autonomous Systems at a rather fast pace. This draft proposes BGP to divide information into two broad categories: Internet routing critical and non Internet routing critical that would also include information carried by BGP which is not related directly to routing. For the purpose of this document we will refer to the latter case as second BGP instance. This draft proposes that the current BGP infrastructure will continue to be used to disseminate Internet routing related information while non routing information or private routing data is recommended to be carried by independent transport instance BGP. |
| | Extensions of Host Identity Protocol (HIP) with Hierarchical Information |
| |
|
This document briefly introduces the benefits brought by extending the Host Identity Protocol (HIP) with hierarchical information. In addition, two hierarchical extensions of HIP are introduced. The first one aims to transport hierarchical information in a parameter of the HIP header, while the second one extends DNS resource records in order to contain hierarchical information. |
| | Rogue IPv6 Router Advertisement Problem Statement |
| |
|
When deploying IPv6, whether IPv6-only or dual-stack, routers are configured to send IPv6 Router Advertisements to convey information to nodes that enable them to autoconfigure on the network. This information includes the implied default router address taken from the observed source address of the Router Advertisement (RA) message, as well as on-link prefix information. However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network. In this draft we summarise the scenarios in which rogue RAs may be observed and present a list of possible solutions to the problem. We focus on the unintended causes of rogue RAs in the text. The goal of this text is to be Informational, and as such to present a framework around which solutions can be proposed and discussed. |
26/05/2009
| |
|
| |
| | LISP Alternative Topology (LISP+ALT) |
| |
| | draft-ietf-lisp-alt-01.txt |
| | Date: |
26/05/2009 |
| | Authors: |
Vince Fuller, Dino Farinacci, Dave Meyer, Darrel Lewis |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
| | Formats: |
txt |
|
This document describes a method of building an alternative, logical topology for managing Endpoint Identifier to Routing Locator mappings using the Locator/ID Separation Protocol. The logical network is built as an overlay on the public Internet using existing technologies and tools, specifically the Border Gateway Protocol and the Generic Routing Encapsulation. An important design goal for LISP+ALT is to allow for the relatively easy deployment of an efficient mapping system while minimizing changes to existing hardware and software. |
| | Interworking LISP with IPv4 and IPv6 |
| |
|
This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP [LISP]) to interoperate with Internet sites not running LISP. A fundamental property of LISP- speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IP addresses, routes for them are not carried in the global routing system so an interoperability mechanism is needed for non-LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces two such mechanisms: the first uses a new network element, the LISP Proxy Tunnel Router (PTR) (Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts while the second adds Network Address Translation (NAT) functionality to LISP Ingress and LISP Egress Tunnel Routers (xTRs) to substitute routable IP addresses for non-routable EIDs. |
| | Host Identity Protocol-based Mobile Router (HIPMR) |
| |
| | draft-melen-hip-mr-02.txt |
| | Date: |
26/05/2009 |
| | Authors: |
Jan Melen, Jukka Ylitalo, Patrik Salmela, Tom Henderson |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This drafts defines a moving network support for HIP enabled hosts. The protocol uses asymmetric authentication and symmetric authorization. The solution presented in this draft is based on delegation of signalling rights between mobile nodes and mobile routers that results in route optimization between end-hosts. |
| | Additional S/MIME Capabilities |
| |
|
This document lists values for the S/MIME Capabilities Attribute. The attribute itself is defined in RFC TBD1, but the values for each are defined in separate algorithm documents and in some cases not at all. The SMIME Capability values can be included in S/MIME messages as a signed attribute and in public key certificates as an extension. //RFC EDITOR: Replace TBD1 with the # assigned to draft-ietf-smime- 3851bis-10.txt. |
| | A SIP server event package for SIP server farm |
| |
|
This document defines the Session Initiation Protocol (SIP) server even package for SIP server farm using the SIP event framework. The SIP server event package allows clients to subscribe to the servers for server information in the server farm, and serves to communicate information with each other. Based on this, an overall view of the SIP server farm is built and delivered to the entity (including SIP phone proxy or other SIP servers) which subscribes and receives the event packages. The view would help failover and load balancing in the server farm. The event notification mechanism of SIP event framework guarantees its adaption to the dynamic changes of server state. We instantiate the usage of SIP server event package in three scenarios: client based failover, DNS based failover, load balancer based load balancing. To be added, we introduce some specific usage in Peer-to-Peer SIP(P2PSIP) and service discovery to expand and explore the potential usage space. Compared with the failover and load balancing mechanisms in traditional SIP, the new SIP event package would apply its explicit and dynamic notification mechanism to improve the efficiency and service availability of SIP server farm. This mechanism using server event package can also be a complementary way for the DNS functionality defined in RFC 3263[RFC 3263] to locate SIP servers. |
25/05/2009
| |
|
| |
| | Validation of Route Origination in BGP using the Resource Certificate PKI |
| |
|
This document defines an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. The proposed application is intended to fit within the requirements for adding security to inter-domain routing, including the ability to support incremental and piecemeal deployment, and does not require any changes to the specification of BGP. |
| | SASL Mechanism Family for External Authentication: EXTERNAL-* |
| |
|
This document describes a way to perform client authentication in the Simple Authentication and Security Layer (SASL) framework by referring to the client authentication provided by an external security layer. We specify a SASL mechanism family EXTERNAL-* and one instance EXTERNAL-TLS that rely on the Transport Layer Security (TLS) protocol. This mechanism differs to the existing EXTERNAL mechanism by alleviating the a priori assumptions that servers and clients needs somehow negotiate out of band which secure channel that is intended. This document also discuss the implementation of authorization decisions. See for more information. |
| | The i;codepoint collation |
| |
|
This memo describes the "i;codepoint" collation. Character strings are compared based on the Unicode scalar values of the characters. The collation supports equality, substring, and ordering operations. |
| | B2BUA with Survivability Feature |
| |
|
This draft describes the behavior of Session Initiation Protocol (SIP) [RFC3261] Back-To-Back User-Agent (B2BUA) with survivability feature, we can define it as a survivable SIP proxy (SSP), and how it should process calls in two different modes one is normal (no- failure) mode and the other is survivable (breakdown) mode. |
| | SMTP Recipient Address Verification Using the Dynamic Delegation Discovery Service (DDDS) |
| |
|
This memo proposes a mechanism based on the Dynamic Delegation Discovery Service (DDDS) which can be used for the verification of SMTP recipient addresses. |
| | Routing Loop Issue in Mobile Ad Hoc Networks (MANETs) |
| |
|
This document describes the routing loop and packet looping issues in mobile ad hoc network (MANET) running proactive routing protocols using hop count metric. Mechanisms of loop formation are identified and how the problem of loop formation is exacerbated by the use of Link Layer Notification is described. The effect of the looping packets on the network are shown by comparing against the case where the looping packets are detected and discarded, showing the need for routing loops or looping packets to be dealt with in MANETs. |
| | A Profile for Bogon Origin Attestations (BOAs) |
| |
|
This document defines a standard profile for Bogon Origin Attestations (BOAs). A BOA is a digitally signed object that provides a means of verifying that an IP address block holder has not authorised any Autonomous System (AS) to originate routes that are equivalent to any of the addresses listed in the BOA. A BOA also provides a means of verifying that a BGP speaker is not using an AS without appropriate authority. The proposed application of BOAs is intended to fit within the requirements for adding security measures to inter-domain routing, including the ability to support incremental and piecemeal deployment of such measures, and does not require any changes to the specification of the Border Gateway Protocol. |
24/05/2009
| |
|
| |
| | RTP Payload Format for Non-Interleaved and Interleaved Parity FEC |
| |
|
This document defines new RTP payload formats for the Forward Error Correction (FEC) that is generated by the non-interleaved and interleaved parity codes from a source media encapsulated in RTP. These parity codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The non-interleaved and interleaved parity codes offer a good protection against random and bursty packet losses, respectively, at a cost of decent complexity. The RTP payload formats that are defined in this document address the scalability issues experienced with the earlier specifications including RFC 2733, RFC 5109 and SMPTE 2022-1, and offer several improvements. Due to these changes, the new payload formats are not backward compatible with the earlier specifications. |
| | IMAP4 Extension for Fuzzy Search |
| |
|
This document describes an IMAP protocol extension enabling server to perform searches with inexact matching and assigning relevancy scores for matched messages.Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to morg@ietf.org. |
23/05/2009
| |
|
| |
| | MPLS Tunnels for Virtual Aggregation |
| |
|
The document "FIB Suppression with Virtual Aggregation" [I-D.francis-intra-va] describes how FIB size may be reduced. The latest revision of that draft refers generically to tunnels, and leaves it to other documents to define the usage and signaling methods for specific tunnel types. This document provides those definitions for MPLS Label Switched Paths (LSP), without tag stacking. |
| | The Uniform Resource Identifier (URI) DNS Resource Record |
| |
|
This document defines a new DNS resource record, called the Uniform Resource Identifier (URI) RR, for publishing mappings from hostnames to URIs. |
| | Atom Export Format |
| |
|
This document specifies a method of using the Atom Syndication Format as an export format. |
19/05/2009
| |
|
| |
| | SDP Capability Negotiation |
| |
|
The Session Description Protocol (SDP) was intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation, however over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these, notably in the form of the offer/answer model defined in RFC 3264. SDP does not define how to negotiate one or more alternative transport protocols (e.g. RTP profiles) or attributes. This makes it difficult to deploy new RTP profiles such as secure RTP or RTP with RTCP-based feedback, negotiate use of different security keying mechanisms, etc. It also presents problems for some forms of media negotiation. The purpose of this document is to address these shortcomings by extending SDP with capability negotiation parameters and associated offer/answer procedures to use those parameters in a backwards compatible manner. The document defines a general SDP Capability Negotiation framework. It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g. media types and media formats) may be provided in other documents. |
| | UA-Driven Privacy Mechanism for SIP |
| |
|
This document defines a guideline for a User Agent (UA) to generate an anonymous Session Initiation Protocol (SIP) message by utilizing mechanisms such as Globally Routable User Agent URIs (GRUU) and Traversal Using Relays around NAT (TURN) without the need for a privacy service defined in RFC 3323. |
18/05/2009
| |
|
| |
| | Domain Certificates in the Session Initiation Protocol (SIP) |
| |
|
This document describes how to construct and interpret certain information in a X.509 PKIX-compliant certificate for use in a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection. More specifically, this document describes how to encode and extract the identity of a SIP domain in a certificate and how to use that identity for SIP domain authentication. As such, this document is relevant both to implementors of SIP and to issuers of cetificates. |
14/05/2009
| |
|
| |
| | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling |
| |
|
This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 3850. |
| | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification |
| |
|
This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. |
13/05/2009
| |
|
| |
| | IMAP4 Extension for returning STATUS information in extended LIST |
| |
|
Many IMAP clients display information about total number of messages/ total number of unseen messages in IMAP mailboxes. In order to do that they are forced to issue a LIST or LSUB command, to list all available mailboxes, followed by a STATUS command for each mailbox found. This document provides an extension to LIST command that allows the client to request STATUS information for mailboxes together with other information typically returned by the LIST command. Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to morg@ietf.org. |
08/05/2009
| |
|
| |
| | SDP and RTSP extensions defined for 3GPP Packet-switched Streaming Service and Multimedia Broadcast/Multicast Service |
| |
|
The Packet-switched Streaming Service (PSS) and the Multimedia Broadcast/Multicast Service (MBMS) defined by 3GPP use SDP and RTSP with some extensions. This document provides information about these extensions and registers the RTSP and SDP extensions with IANA. |
05/05/2009
| |
|
| |
| | RTP Payload Format for 1-D Interleaved Parity FEC |
| |
|
This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of decent complexity. The new payload format defined in this document is used (with some exceptions) as a part of the DVB Application-layer FEC specification. |
| | GRE Key Option for Proxy Mobile IPv6 |
| |
|
This specification defines a new Mobility Option for allowing the mobile access gateway and the local mobility anchor to negotiate GRE (Generic Routing Encapsulation) encapsulation mode and exchange the downlink and uplink GRE keys which are used for marking the downlink and uplink traffic that belong to a specific mobility session. In addition, the same mobility option can be used to negotiate the GRE encapsulation mode without exchanging the GRE keys. |
04/05/2009
| |
|
| |
| | Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery |
| |
|
This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options that contain a list of IP addresses and a list of domain names that can be mapped to servers providing IEEE 802.21 type of Mobility Service (MoS)[MSFD]. These Mobility Services are used to assist a mobile node (MN) in handover preparation (network discovery) and handover decision (network selection). The services addressed in this document are the Media Independent Handover Services defined in [IEEE802.21]. |
| | Advertising a Router's Local Addresses in OSPF TE Extensions |
| |
|
OSPF Traffic Engineering (TE) extensions are used to advertise TE Link State Advertisements (LSAs) containing information about TE- enabled links. The only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE- enabled links, and the local address corresponding to the Router ID. In order to allow other routers in a network to compute Multiprotocol Label Switching (MPLS) traffic engineered Label Switched Paths (TE LSPs) to a given router's local addresses, those addresses must also be advertised by OSPF TE. This document describes procedures that enhance OSPF TE to advertise a router's local addresses. |
|
