|
Internet Drafts - IDs for Aug/2009
Index - Month Index of IDs
All IDs - sorted by date)
31/08/2009
| |
|
| |
| | Requirements for OAM in MPLS Transport Networks |
| |
|
This document lists architectural and functional requirements for the Operations, Administration and Maintenance of MPLS Transport Profile. These requirements apply to pseudowires, Label Switched Paths, and Sections. |
30/08/2009
| |
|
| |
| | Using and Extending the NSIS Protocol Family |
| |
| | draft-ietf-nsis-ext-04.txt |
| | Date: |
30/08/2009 |
| | Authors: |
Jukka Manner, Roland Bless, John Loughney, Elwyn Davies |
| | Working Group: |
Next Steps in Signaling (nsis) |
| | Formats: |
txt xml |
|
This document gives an overview of the Next Steps in Signaling (NSIS) framework and protocol suite created by the NSIS working group during the period 2001-2009 together with suggestions on how the industry can make use of the new protocols, and how the community can exploit the extensibility of both the framework and existing protocols to address future signaling needs. |
28/08/2009
| |
|
| |
| | HTTP Enabled Location Delivery (HELD) |
| |
|
A Layer 7 Location Configuration Protocol (L7 LCP) is described that is used for retrieving location information from a server within an access network. The protocol includes options for retrieving location information in two forms: by value and by reference. The protocol is an extensible application-layer protocol that is independent of session-layer. This document describes the use of HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer Security (HTTP/TLS) as transports for the protocol. |
| | BGP Bestpath Selection Criteria |
| |
|
BGP specification [RFC4271] prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. This document defines enhances the "Route Resolvability Condition" to facilitate the next-hop to be resolved in the chosen data plane. |
| | Signaling LDP Label Advertisement Completion |
| |
|
There are situations following Label Distribution Protocol (LDP) session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels. The LDP specification provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer. This document specifies means for an LDP speaker to signal completion of its initial label advertisements following session establishment. |
| | Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer |
| |
|
This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies: Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. |
| | Transport Considerations for DNS |
| |
|
DNS queries and responses are available over a variety of transports (UDP/TCP) and may be ported to use other transports in the future. Current use profiles show that most user generated DNS traffic prefers one transport over another. This historical usage pattern has or may lead to the presumption that any DNS traffic, regardless of transport, should be considered on equal footing. |
27/08/2009
| |
|
| |
| | Use of Target Identity in HTTP-Enabled Location Delivery (HELD) |
| |
|
When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP Enabled Location Delivery (HELD) specification, it uses the source IP address of arriving message as a pointer to the location determination process. This is sufficient in environments where the location of a Device can be determined based on its IP address. Two additional use cases are addresses by this document. In the first, location configuration requires additional or alternative identifiers from the source IP address provided in the request. In the second, an entity other than the Device requests the location of the Device. This document extends the HELD protocol to allow the location request message to carry Device identifiers. Privacy and security considerations describe the conditions where requests containing identifiers are permitted. |
| | RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support |
| |
|
This document defines a set of RADIUS Attributes which are designed to provide RADIUS support for IEEE 802.16 Privacy Key Management Version 1. |
| | Extension of DHCPv4 for policy routing of multiple interfaces terminal |
| |
|
Current multiple interfaces terminal causes the problem of selecting a proper interface for a specific application, and this is a new question which will change the previous internet model. This document proposes a solution which uses policy routing to map the IP flows to multiple interfaces. |
| | An Analysis of Scaling Issues for Point-to-Multipoint Label Switched Paths in MPLS-TE Core Networks |
| |
|
Traffic engineered Multiprotocol Label Switching (MPLS-TE) is deployed in providers' core networks, and the scaling properties have been analyzed to show how much control state must be maintained to support a full mesh of edge-to-edge point-to-point (P2P) Label Switched Paths (LSPs) in various network topologies and with several different scaling techniques. Point-to-multipoint (P2MP) MPLS-TE LSPs are very interesting to service providers as a means to provide multicast services (such as TV distribution, or multicast VPN connectivity) across core MPLS networks. P2MP LSPs have different scaling properties than P2P LSPs, and service providers need to understand whether existing protocols and implementations can support the network sizes and service levels that they are planning in their P2MP MPLS-TE networks. This document presents an analysis of the scaling properties MPLS-TE core networks that support P2MP LSPs. |
| | Cryptographic Algorithm Identifier Allocation for DNSSEC |
| |
|
This document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated. It changes the rule from "standard required" to "RFC required". |
| | A Note on NAT64 Interaction with Mobile IPv6 |
| |
|
This memo discusses potential NAT64 technology repercussions for mobile nodes using Mobile IPv6 stack. |
| | Sieve Extension: Externally Stored Lists |
| |
|
The Sieve scripting language can be used to implement whitelisting, blacklisting, and personal distribution lists. Currently, this requires that all members of such lists be hardcoded in the script itself. Whenever a member of a list is added or deleted, the script needs to be updated and possibly uploaded to a mail server. This document defines a Sieve extension for accessing externally stored lists -- lists whose members are stored externally to the script, such as using LDAP (RFC 4510), ACAP (RFC 2244), or relational databases. ToDo o Need a way to advertise supported URI schemas in ManageSieve and ihave. |
| | Presence Interdomain Scaling Analysis for SIP/SIMPLE |
| |
|
This document analyzes the traffic that is generated by presence subscriptions between domains and shows that the amount of traffic can be extremely large. This document also analyzes the effects of a large presence system on the memory footprint and the CPU load. Approved and in-work optimizations to the Session Initiation Protocol are analyzed, considering the possible impact on the load. Separate documents contain the requirements for optimizations and suggestions for new optimizations. |
| | Requirements for End-to-End Encryption in the Extensible Messaging and Presence Protocol (XMPP) |
| |
|
This document describes requirements for end-to-end encryption in the Extensible Messaging and Presence Protocol (XMPP). |
26/08/2009
| |
|
| |
| | Make TCP more Robust to Long Connectivity Disruptions |
| |
|
Disruptions in end-to-end path connectivity which last longer than one retransmission timeout cause suboptimal TCP performance. The reason for the performance degradation is that TCP interprets segment loss induced by connectivity disruptions as a sign of congestion, resulting in repeated backoffs of the retransmission timer. This leads in turn to a deferred detection of the re-establishment of the connection since TCP waits until the next retransmission timeout occurs before attempting the retransmission. This document describes how standard ICMP messages can be exploited to disambiguate true congestion loss from non-congestion loss caused by long connectivity disruptions. Moreover, a revert strategy of the retransmission timer is specified that enables a more prompt detection of whether the connectivity to a previously disconnected peer node has been restored or not. The specified algorithm is a TCP sender-only modification that effectively improves TCP performance in presence of connectivity disruptions. |
| | DNSCurve: Link-level security for the Domain Name System |
| |
|
This document describes DNSCurve, a protocol extension that adds link-level security to the Domain Name System (DNS). |
25/08/2009
| |
|
| |
| | EDNS Page Option |
| |
|
Describes an EDNS option to allow large DNS responses to be sent using small UDP packets. |
24/08/2009
| |
|
| |
| | The 'javascript' resource identifier scheme |
| |
|
This memo defines the 'javascript' resource identifier scheme. Using this scheme, executable script code can be specified in contexts that support resource identifiers. |
| | MVPN: Optimized use of PIM,Wild Card Selectors,S-PMSI Join Extensions,Bidirectional Tunnels,Extranets,Hub and Spoke |
| |
|
Specifications for a number of important topics were arbitrarily omitted from the initial MVPN specifications, so that those specifications could be "frozen" and advanced. The current document provides some of the missing specifications. The topics covered are: (a) Extending PE-PE PIM control mechanisms to support MPLS tunnels and IPv6 flows, (b) using Wild Card selectors to bind multicast data streams to tunnels, (c) using Multipoint-to-Multipoint Label Switched Paths as tunnels, (d) binding bidirectional customer multicast data streams to specific tunnels, (e) running PIM (i.e., sending and receiving multicast control traffic) over a set of tunnels that are created only if needed to carry multicast data traffic, (f) extranets, (g) support for anycast sources, (h) support for "hub and spoke" VPNs. |
| | Fast Tree Join for Seamless Multicast Handover in Wireless/Mobile Networks |
| |
|
This draft describes a fast handover mechanism to provide seamless multicast services in the wireless/mobile networks based on the Fast Mobile IPv6 (FMIPv6). When a mobile node (MN) moves from one access router to another, it may encounter data loss. In the tree joining case of the existing scheme, there is a problem of buffer overflow during the packet forwarding from Previous Access Router (PAR) to New Access Router (NAR), in which many packet losses may occur due to the buffer overflow. In order to reduce this buffer overflow and the concerned packet losses, we propose a new scheme of a fast tree join for seamless multicast handover, which allows the NAR to join the multicast tree before the FMIPv6 handover is completed. In the proposed scheme, we consider the two specific cases: 1) the short tree joining time, in which no packet forwarding will be required and thus NAR can receive the multicast data from an upstream multicast router before the FMIPv6 handover is completed, 2) the long tree joining time, in which the packet forwarding will be required and thus NAR will receive the multicast data after the FMIPv6 handover. |
| | Policy Decisions and IASA -- IETF Trust and IAOC Issues |
| |
|
Experience has indicated that the role of the various components of the IETF Administrative Support Activity (IASA) in developing and setting policies is not sufficiently clear in the defining documents. This document provides an explicit statement of principles for policy formulation and decision-making about areas of IASA responsibility. |
| | QMIP: Query-based Mobile IP |
| |
|
Mobile IP (MIP) suffers from the so-called triangular routing problem. Moreover, MIP Home Agent (HA) tends to undergo severe data traffic load, since it should deliver all the data packets toward mobile nodes. This paper proposes a simple extension of MIP, called Query- based MIP (QMIP), in which the binding query to HA will be used to get the care-of address of a mobile node and to deliver the subsequent data packets over the optimized data path. The proposed QMIP scheme can be applied to MIPv4 and Proxy MIPv6 as well. |
| | OCSP Algorithm Agility |
| |
|
The OSCP specification defined in RFC 2560 requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used leading to possible interoperability failures in contexts where multiple signature algorithms are in use. This document specifies an algorithm for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. |
| | A Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure |
| |
|
This document defines a profile for the algorithm and key size to be used for signatures applied to certificates, Certificate Revocation Lists, and signed objects in the context of the Resource Public Key Infrastructure. |
| | VoIP SIP Peering Use Cases |
| |
|
This document depicts many common Voice over IP (VoIP) use cases for Session Initiation Protocol (SIP) Peering. These use cases are categorized into static and on-demand, and then further sub- categorized into direct and indirect. These use cases are not an exhaustive set, but rather the most common use cases deployed today. |
| | ICMP attacks against TCP |
| |
|
This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP) and other similar protocols. Additionally, describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. |
23/08/2009
| |
|
| |
| | Diameter Extended NAPTR |
| |
|
This document describes an extended format for the NAPTR service fields used in dynamic Diameter agent discovery. The extended format allows NAPTR queries contain Diameter Application-Id information. |
| | RTP Payload Format for DRA Audio |
| |
| | draft-xu-avt-dra-00.txt |
| | Date: |
23/08/2009 |
| | Authors: |
Mao Xu, ChuSheng Zheng, Tian Jiang, WeiXiong Zhang, JingPing Zhang |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
The present document describes a RTP packaging scheme for DRA compressed audio data transmission, as well as the corresponding RTP payload format. According to the properties of DRA compressed audio frame and the Maximum Transmission Unit (MTU) of network, the scheme provides 3 packaging modes for different coding and transmission requirements. |
21/08/2009
| |
|
| |
| | DNSSEC Trust Anchor History Service |
| |
|
When DNS validators have trusted keys, but have been offline for a longer period, key rollover will fail and they are stuck with stale trust anchors. History service allows validators to query for older DNSKEY RRsets and pick up the rollover trail where they left off. |
| | Transport Layer Security and Datagram Transport Layer Security Heartbeat Extension |
| |
|
This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocol. The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for PMTU discovery for DTLS. |
20/08/2009
| |
|
| |
| | CalDAV Scheduling Extensions to WebDAV |
| |
|
This document defines extensions to the CalDAV "calendar-access" feature to specify a standard way of performing scheduling transactions with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV. |
| | HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- layer Protocol Signaling (HICCUPS) |
| |
|
This document defines a new HIP (Host Identity Protocol) packet type called DATA. HIP DATA packets are used to securely and reliably convey arbitrary protocol messages over the Internet and various overlay networks. |
| | The UDP Tunnel Transport mode |
| |
|
This document proposes a standards track protocol called the UDP Tunnel Transport. This protocol updates the UDP processing of RFC 2460 for IPv6 hosts and routers. The update enables a sender to generate a UDP datagram where the UDP checksum is replaced by a header check determined only by the protocol header information. For this use, the document also updates the way the IPv6 UDP length field is interpreted. This mode is intended to minimise the processing cost for the transport of tunnel packets using UDP. |
| | Host Identity Protocol-based Mobile Proxy |
| |
|
This document defines a HIP-proxy node that enables non-HIP host to communicate with HIP host through a proxy node without requiring changes to the non-HIP host. |
| | A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem |
| |
|
A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used traditionally for file-sharing, and more recently for real-time communications and live media streaming. Such applications discover a route to each other through an overlay network with little knowledge of the underlying network topology. As a result, they may choose peers based on information deduced from empirical measurements, which can lead to suboptimal choices. We refer to this as the Application Layer Traffic Optimization (ALTO) problem. In this draft we present a survey of existing literature on discovering topology characteristics. |
| | Improving Peer Selection in Peer-to-peer Applications: Myths vs. Reality |
| |
|
Peer-to-peer traffic optimization techniques that aim at improving locality in the peer selection process have attracted great interest in the research community and have been subject of much discussion. Some of this discussion has produced controversial myths, some rooted in reality while others remain unfounded. This document evaluates the most prominent myths attributed to P2P optimization techniques by referencing the most relevant study (or studies) that have addressed facts pertaining to the myth. Using these studies, we hope to either confirm or refute each specific myth. |
| | Experience with rsvp-te p2mp based mvpn |
| |
|
Multicast based VPNs have been deployed for a while now, based on the Draft Rosen solution. In today's scenario, network deployments are moving towards a choice Label Switched Multicast, primarily to garner some of the advantages that a Label Switched Network can offer. In short, the requirement is to achieve more optimal multicast replication and in other words achieve better and effective bandwidth savings. This document describes some of the experiences gained from the implementation and deployment of Label Switched multicast using the RSVP-TE P2MP Label Switched Path approach, and such is information only. The intent is to translate the experiences gained into valuable practices for the Service Provider and Enterprise community who intend to deploy this class of mVPNs. Information based on "Hierarchical Multicast Trees" and "Aggregated P Tunnels" have not been included, and will follow in the next version of this draft. |
| | Relay Usage for ALTO in Real Time Communication |
| |
| | draft-meng-alto-relay-00.txt |
| | Date: |
20/08/2009 |
| | Authors: |
Yu Meng, Jun Wang, Tao Ma, Hui Wang, Miao Xiong |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
ALTO has been proposed to help peer-to-peer (P2P) applications make better decisions with respect to peer selection. It provides the underlying network view for P2P users to choose the optimal resource instances. The usage of ALTO has covered nearly all the P2P applications, such as file sharing, media streaming, real time communications and etc. In real time communication where the source and destination are fixed, it is used to choose relays. This document defines the relay usage for ALTO in real time communication. Beside the relay for NAT traversal mentioned before, this document introduce a relay called Qos relay to improve the performance. After analyzing the necessity of this type of relay and the benefits of combining ALTO with relay, two models of combination are described according to the coupling tightness between ALTO and relay service. One is called "integrating relay service into alto service" and the other is "cooperation between P2P application provider and ISP". In all, the usage of ALTO in real time communication has been developed in this document. |
| | Security Assessment of the Internet Protocol version 4 |
| |
|
This document contains a security assessment of the IETF specifications of the Internet Protocol version 4, and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). |
| | PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering |
| |
|
The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered client/server networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "PCE Communication Protocol Generic Requirements". Generic requirements for PCE discovery protocol are presented in "Requirements for Path Computation Element (PCE) Discovery". This document complements the generic requirements and presents detailed sets of PCC-PCE communication protocol requirements and PCE discovery protocol requirements for inter-layer traffic engineering. |
19/08/2009
| |
|
| |
| | SDP Elements for FEC Framework |
| |
|
This document specifies the use of Session Description Protocol (SDP) to describe the parameters required to signal the Forward Error Correction (FEC) Framework Configuration Information between the sender(s) and receiver(s). This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework. |
| | Channel Bindings for TLS based on the PRF |
| |
|
This document specify how to compute data, "channel bindings", that is cryptographically bound to a specific Transport Layer Security (TLS) session. The intention is to use this data as a name of the secure channel for the purpose of a channel binding. The channel bindings can be used by authentication protocols to avoid tunneling attacks and security layer re-use. The data is derived using the TLS Pseudo-Random Function (PRF). |
| | Special Use IPv4 Addresses |
| |
|
This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. |
| | Use of SRV records for locating email services |
| |
|
This specification describes how SRV records can be used to locate email services. |
| | Mobile Multicast Control Protocol in Wireless/Mobile Networks |
| |
| | draft-dykim-mmcp-00.txt |
| | Date: |
19/08/2009 |
| | Authors: |
Dae Young Kim, Seok Koh |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document is a part of the ITU-T Recommendation and ISO/IEC International Standard, named the Mobile Multicast Communications Protocol (MMCP). The MMCP is a protocol that can be used to support a variety of multimedia multicasting services in the IP-based wireless mobile networks. The MMCP is targeted at the real-time one-to-many multicast services and applications over mobile communications networks. |
| | Security Assessment of the Transmission Control Protocol (TCP) |
| |
|
This document contains a security assessment of the specifications of the Transmission Control Protocol (TCP), and of a number of mechanisms and policies in use by popular TCP implementations. Additionally, it contains best current practices for hardening a TCP implementation. |
18/08/2009
| |
|
| |
| | Multicast in MPLS/BGP IP VPNs |
| |
|
This draft describes the deployed MVPN (Multicast in BGP/MPLS IP VPNs) solution of Cisco Systems. |
| | Mutual Authentication Protocol for HTTP |
| |
|
This document specifies the "Mutual authentication protocol for Hyper-Text Transport Protocol". This protocol provides true mutual authentication between HTTP clients and servers using simple password-based authentication. Unlike Basic and Digest HTTP access authentication protocol, the protocol ensures that server knows the user's entity (encrypted password) upon successful authentication. This prevents common phishing attacks: phishing attackers cannot convince users that the user has been authenticated to the genuine website. Furthermore, even when a user has been authenticated against an illegitimate server, the server cannot gain any bit of information about user's passwords. The protocol is designed as an extension to the HTTP protocol, and the protocol design intends to replace existing authentication mechanism such as Basic/Digest access authentications and form-based authentications. |
| | P2MP traffic protection in MPLS-TP ring topology |
| |
|
Purpose of this ID is to describe requirements and possible solutions for point to multipoint (P2MP) traffic distribution over interconnected MPLS-TP rings. The rationale for an ID on such a specific application is illustrated in the rest of the document. |
| | Signaling Compression dictionary for SIP |
| |
|
The SigComp static dictionary for Session Initiation Protocol (SIP) signalling was done by first version RFC3485. SIP protocol related extensions were completed and published in a series IETF documents. Those SIP protocol extensions had been used in 3GPP IMS and IMS based applications. The new extensions to SIP protocol weaken the intention of static dictionary for SIP signalling compressing which is to reduce overload risks in radio access network and core network involving wireless network. |
17/08/2009
| |
|
| |
| | xDSL multi-pair bonding using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB |
| |
|
This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP based internets. This document proposes an extension to the G.Bond MIB module with a set of objects for managing multi-pair bonded xDSL interfaces using Time-Division Inverse Multiplexing (TDIM), defined in ITU-T recommendation G.998.3. |
| | Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO) |
| |
|
The Geopriv Location Object introduced by the Presence Information Data Format - Location Object (PIDF-LO), RFC 4119, defines a basic XML format for carrying geographical information of a presentity. This document defines PIDF-LO extensions that are intended to convey information about moving objects. Elements are defined that enable expression of spatial orientation, speed, heading, and acceleration of the presentity. |
| | Requirements of an Audio Communication System (ACS) |
| |
|
This document describes the requirements of an audio communication system (ACS) for acoustic content, especially speech and music. The ACS consists of all components above the IP layer and below a digital PCM audio interface. These include codec, jitter buffer, and transport. The goal of the ACS is to provide a bidirectional acoustic communication between any two Internet hosts at a good quality, constrained only by the available resources at the hosts and the characteristics of the transmission path between both hosts. The intention of the document is to provide the requirements for a codec that is solely intended for the Internet, to provide the requirements for the codec's payload specification, and to define the requirements on the transport protocol. |
| | Preliminary Evaluation of RFC 1652 for Advancement to Full Standard |
| |
|
This memo is a preliminary evaluation of RFC 1652 "SMTP Service Extension for 8bit-MIMEtransport" for advancement from Draft to Full Standard. It has been prepared by the The Yet Another Mail Working Group. THIS INTERNET DRAFT IS WRITTEN TO FACILITATE PROCESSING WITHIN THE IESG. IT IS NOT MEANT TO BE PUBLISHED AS AN RFC. |
16/08/2009
| |
|
| |
| | OSPFv2 Routing Protocols Extensions for ASON Routing |
| |
|
The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks. The requirements for GMPLS routing to satisfy the requirements of ASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON. Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. |
14/08/2009
| |
|
| |
| | P-Charge-Info - A Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) |
| |
|
This document describes 'P-Charge-Info', a private Session Initiation Protocol (SIP) header (P-header) used to convey billing information about the party to be charged. This P-Header is currently in production usage by a number of equipment vendors and carriers and this document is submitted to request the registration of this header with IANA as required by section 4.2 of RFC 3427 and RFC 3968. This P-Header may also be used in some situations to carry the ISUP Charge Number parameter for PSTN interconnection. |
| | P2PSIP Security Requirements |
| |
|
This draft discusses the security requirements in Peer-to-Peer (P2P) SIP system. As the P2P SIP is distributed and each peer is equal in it, it should face the extra security threat from traditional system. This draft introduces these security threats at first. After that, the security requirements of P2P SIP system were brought up. |
| | Benchmarking Methodology for Data Center Bridging Devices |
| |
|
Existing benchmarking methodologies are based on the assumption that networking devices will drop network traffic at their performance limits. Data Center Bridging (DCB) devices, however, will attempt to throttle network endpoints before those limits are reached in order to minimize the probability of frame loss in the network. Hence, existing methodologies based around frame loss are inappropriate for DCB devices. This document takes the basic benchmarking ideas based on loss and extends them to support "lossless" Ethernet devices. |
13/08/2009
| |
|
| |
| | CAPWAP Protocol Base MIB |
| |
| | draft-ietf-capwap-base-mib-06.txt |
| | Date: |
13/08/2009 |
| | Authors: |
Yang Shi, David Perkins, Chris Elliott, Yong Zhang |
| | Working Group: |
Control And Provisioning of Wireless Access Points (capwap) |
| | Formats: |
txt |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes the managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. |
| | CAPWAP Protocol Binding MIB for IEEE 802.11 |
| |
| | draft-ietf-capwap-802dot11-mib-05.txt |
| | Date: |
13/08/2009 |
| | Authors: |
Yang Shi, David Perkins, Chris Elliott, Yong Zhang |
| | Working Group: |
Control And Provisioning of Wireless Access Points (capwap) |
| | Formats: |
txt |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol for IEEE 802.11 wireless binding. |
| | New ASN.1 Modules for PKIX |
| |
|
The PKIX certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. |
| | Segmented Pseudowire |
| |
| | draft-ietf-pwe3-segmented-pw-13.txt |
| | Date: |
13/08/2009 |
| | Authors: |
Luca Martini, Thomas Nadeau, Chris Metz, Michael Duckett, Matthew Bocci, Florin Balus, Mustapha Aissaoui |
| | Working Group: |
Pseudowire Emulation Edge to Edge (pwe3) |
| | Formats: |
txt |
|
This document describes how to connect pseudowires (PW) between two distinct PW control planes or PSN domains. The PW control planes may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point. The PW packet data units are simply switched from one PW to another without changing the PW payload. |
| | New ASN.1 Modules for CMS and S/MIME |
| |
|
The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. |
12/08/2009
| |
|
| |
| | Unintended Consequence of two NAT deployments with Overlapping Address Space |
| |
|
This document identifies two deployment scenarios that have arisen from the unconventional network topologies formed using Network Address Translator devices (NATs). First, the simplicity of administering networks through the combination of NAT and DHCP has increasingly lead to the deployment of multi-level inter-connected private networks involving overlapping private IP address spaces. Second, the proliferation of private networks in enterprises, hotels and conferences, and the wide spread use of Virtual Private Networks (VPNs) to access enterprise intranet from remote locations has increasingly lead to overlapping private IP address space between remote and corporate networks. The document does not dismiss these unconventional scenarios as invalid, but recognizes them as real and offers recommendations to help ensure these deployments can function without a meltdown. |
| | Delay-Tolerant Networking Bundle-in-Bundle Encapsulation |
| |
|
This document defines an encapsulation-specific application agent capability and a bundle payload format for use with the Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant Network architecture [refs.DTNarch]. It defines the capability and format for placing one or more bundles inside of the payload field of an encapsulating bundle's Bundle Payload Block. |
| | Delay-Tolerant Networking Custodial Multicast Extensions |
| |
|
This document defines optional extensions to the Bundle Protocol [refs.DTNBP] for supporting the custodial multicast delivery of bundles within a Delay-Tolerant Network (DTN). The protocol extensions described herein may be used to support custody transfer and custody-based reforwarding during the transmission of a bundle from a single source node to multiple destination nodes. |
| | The 'about' URI scheme |
| |
|
This document specifies the URI (Uniform Resource Identifier) scheme "about". About URIs are designed to be an internal, application- level identifier. Unlike many other URI schemes, the resolution of, and resources represented by, about URIs are left largely to each individual application. Only the "about:blank" URI must be the same. |
| | Delay-Tolerant Networking Bundle Diversion |
| |
|
This document defines two extensions to the capabilities of a Bundle Protocol Agent (BPA) (as defined in [refs.DTNBP]) that is processing bundles within the context of a Delay-Tolerant Network architecture [refs.DTNarch]. It defines an operation called "diversion", which is the act of a bundle protocol agent moving an entire bundle from some point in bundle processing in the BPA to a DTN application agent. This diversion of a bundle from the BPA to an application agent is distinct from delivery of the bundle at that application agent. This document defines a second operation, called "injection", which is the inverse of diversion. Injection is the act of an application agent moving an entire bundle from the application agent into some point in bundle processing in the BPA. This injection of a bundle from an application agent to the BPA is distinct from bundle transmission. |
| | Integration of Robust Header Compression (ROHC) over IPsec Security Associations |
| |
|
IP Security (IPsec) provides various security services for IP traffic. However, the benefits of IPsec come at the cost of increased overhead. This document outlines a framework for integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec). By compressing the inner headers of IP packets, ROHCoIPsec proposes to reduce the amount of overhead associated with the transmission of traffic over IPsec Security Associations (SAs). |
| | IKEv2 Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec) |
| |
|
In order to integrate ROHC with IPsec [ROHCOIPSEC], a mechanism is needed to signal ROHC channel parameters between end-points. Internet Key Exchange (IKE) is a mechanism which can be leveraged to exchange these parameters. This document specifies extensions to IKEv2 [IKEV2] that will allow ROHC and its associated channel parameters to be signaled for IPsec security associations (SAs). |
| | IPsec Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec) |
| |
|
Integrating ROHC with IPsec (ROHCoIPsec) offers the combined benefits of IP security services and efficient bandwidth utilization. However, in order to integrate ROHC with IPsec, extensions to the SPD and SAD are required. This document describes the IPsec extensions required to support ROHCoIPsec. |
11/08/2009
| |
|
| |
| | Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping |
| |
| | draft-ietf-mpls-p2mp-lsp-ping-08.txt |
| | Date: |
11/08/2009 |
| | Authors: |
Seisho Yasukawa, Adrian Farrel, Zafar Ali, Bill Fenner, George Swallow, Thomas Nadeau, Shaleen Saxena |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
| | Formats: |
txt |
|
Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs. The requirement for a simple and efficient mechanism that can be used to detect data plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP Ping". The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP Ping to the MPLS P2MP environment. |
| | IANA IPv4 Special Purpose Address Registry |
| |
|
This is a direction to IANA concerning the creation and management of the IANA IPv4 Special Purpose Address Registry. |
| | Advanced Security Processing for Atom and APP Documents |
| |
|
The Atom and APP specifications specify simple uses of cryptography to sign and encrypt their documents. Each document is processed completely, and in isolation. This document specifies additional uses that enable selective protection or encryption of content, and allow a "trust path" to be created across "atom:link" elements. |
| | A Protocol for Provisioning Resource Certificates |
| |
|
This document defines a framework for certificate management interactions between a resource issuer ("Internet Registry" or "IR") and a resource recipient ("Internet Service Provider" or "ISP") through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the ISP, and corresponding responses from the IR encompassing the actions of certificate issuance, certificate revocation and certificate status information reports. This protocol is intended to be limited to the application of resource certificate management and is not intended to be used as part of a more general certificate management framework. |
| | Media Resource Control Protocol Version 2 (MRCPv2) |
| |
|
The MRCPv2 protocol allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol - it relies on other protocols, such as Session Initiation Protocol (SIP) to rendezvous MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover and exchange capabilities. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 protocol exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. |
10/08/2009
| |
|
| |
| | RTP Payload Format for MIDI |
| |
|
This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. |
| | NewReno Modification for Smooth Recovery After Fast Retransmission |
| |
|
This memo describes a feeble point in Fast Recovery algorithm in NewReno defined in RFC3782 and proposes a simple modification to solve the problem. |
09/08/2009
| |
|
| |
| | Password Policy for LDAP Directories |
| |
|
Password policy as described in this document is a set of rules that controls how passwords are used and administered in Lightweight Directory Access Protocol (LDAP) based directories. In order to improve the security of LDAP directories and make it difficult for password cracking programs to break into directories, it is desirable to enforce a set of rules on password usage. These rules are made to ensure that users change their passwords periodically, passwords meet construction requirements, the re-use of old password is restricted, and to deter password guessing attacks. |
| | An Approach for Using LDAP as a Network Information Service |
| |
|
This document describes a mechanism for mapping entities related to TCP/IP and the UNIX system [UNIX] into [X.500] entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC4511]. A set of attribute types and object classes are proposed, along with specific guidelines for interpreting them. The intention is to assist the deployment of LDAP as an organizational nameservice. No proposed solutions are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, leading eventually to the adoption of standards. The proposed mechanism has already been implemented with some success. |
| | DTN IP Neighbor Discovery (IPND) |
| |
|
Disruption Tolerant Networking (DTN) IP Neighbor Discovery (IPND), is a method for otherwise oblivious nodes to learn of the existence, availability, and addresses of other DTN participants. IPND both sends and listens for small IP UDP announcement "beacons." Beacon messages are addressed to an IP unicast, multicast, or broadcast destination to discover specified remote neighbors, or unspecified local neighbors in the topology, e.g. within wireless range. IPND beacons advertise neighbor availability by including the DTN node's canonical endpoint identifier. IPND beacons optionally include service availability and parameters. In this way, neighbor discovery and service discovery may be coupled or decoupled as required. Once discovered, new neighbor pairs use advertised availabilities to connect, exchange routing information, etc. This document describes DTN IPND. |
07/08/2009
| |
|
| |
| | ALTO Information Redistribution Considered Harmful |
| |
|
The merged ALTO protocol proposal proposes several mechanisms to increase scalability of the protocol. One of the proposed mechanisms is the distribution of ALTO information directly between the peers without any involvement of the server. This memo discusses why the proposed mechanism is considered harmful and why the proposed security framework is deployable. |
| | A routing method based on detection frames over LLNs |
| |
|
This document presents a routing method through sending detection frames including address of destination node to the neighbor nodes to reduce delay of data transmission because of the dormant nodes will increase data transmission delay in low power and lossy networks(LLNs). When receives the response from the neighbor nodes, the sending node can select a neighboring node as the next hop node to sent data, which has the lower cost parameter than the cost parameter between the sending node and the destination node stored in the routing table of sending node. This routing method finds a route in real-time by broadcasting detection frames. As long as any neighbor node that can reach the destination is active, data can be sent and then the data transmission delay will be reduced. |
06/08/2009
| |
|
| |
| | EAP-Support in Smartcard |
| |
|
This document describes the functional interface, based on the ISO7816 standard, to EAP methods, fully and securely executed in smart cards. This class of tamper resistant device may deliver client or server services; it can compute Root Keys from an Extended Master Session Key (EMSK). |
| | FLUTE - File Delivery over Unidirectional Transport |
| |
|
This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This document obsoletes RFC3926. |
05/08/2009
| |
|
| |
| | Prefix Management for Mobile IPv6 Fast Handover on Point-to-Point Links |
| |
|
Mobile IPv6 Fast Handovers specification currently does not explicitly define prefix management over point-to-point links when a mobile node uses a prefix to formulate a new care-of-address. In this document a mechanism is developed for a previous access router to request unique prefixes from a new access router, and in turn, the previous access router advertises the prefixes to the mobile node for a new care-of-address configuration. Extensions to Mobile IPv6 Fast Handovers specification are also specified in this document. |
| | Using TCP Selective Acknowledgement (SACK) Information to Determine Duplicate Acknowledgements for Loss Recovery Initiation |
| |
|
This document describes a TCP sender algorithm to trigger loss recovery based on the information gathered on a SACK scoreboard instead of simply counting the number of arriving duplicate acknowledgements in the traditional way. The given algorithm is more robust to ACK losses, ACK reordering, missed duplicate acknowledgements due to delayed acknowledgements, and extra duplicate acknowledgements due to duplicated segments and out-of- window segments. The algorithm allows not only a timely initiation of TCP loss recovery but also reduces false fast retransmits. It has a low implementation cost on top of the SACK scoreboard defined in RFC 3517. |
| | Session-Specific Explicit Diameter Request Routing |
| |
|
This document describes a mechanism to enable specific Diameter proxies to remain in the path of all message exchanges constituting a Diameter session. |
| | Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC |
| |
|
This document describes how to produce GOST signature and hash algorithms DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). V.Dolmatov Expires February 05, 2010 [page 1] |
| | Validation of Route Origination in BGP using the Resource Certificate PKI and ROAs |
| |
|
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 requirement 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. |
| | Connection Reuse in the Session Initiation Protocol (SIP) |
| |
|
This document enables a pair of communicating proxies to reuse a congestion-controlled connection between themselves for sending requests in the forward and backwards direction. Because the connection is essentially aliased for requests going in the backwards direction, reuse is predicated upon both the communicating endpoints authenticating themselves using X.509 certificates through TLS. For this reason, we only consider connection reuse for TLS over TCP and TLS over SCTP. This document also provides guidelines on connection reuse and virtual SIP servers and the interaction of connection reuse and DNS SRV lookups in SIP. |
04/08/2009
| |
|
| |
| | DHCPv4 Vendor-specific Message |
| |
|
This document requests a vendor-specific DHCPv4 message assignment. This message can be used for vendor specific and experimental purposes. |
| | DHCPv6 Vendor-specific Message |
| |
|
This document requests a vendor-specific DHCPv6 message assignment. This message can be used for vendor specific and experimental purposes. |
| | Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN |
| |
|
Today, customers expect to run triple play services through BGP/MPLS IP-VPNs. Some Service Providers will deploy services that request QoS guarantees from a local CE to a remote CE across the network. As a result, the application (e.g., voice, video, bandwidth-guaranteed data pipe, etc.) requirements for end-to-end QOS and reserving adequate bandwidth continue to increase. Service Providers can use both MPLS and an MPLS-TE LSP to meet the service objectives. This document describes service provider requirements for supporting customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN. |
| | AAA and Admission Control Framework for Multicasting |
| |
|
IP multicast-based services, such as TV broadcasting or videoconferencing raise the issue of making sure that potential customers are fully entitled to access the corresponding contents. There is indeed a need for service and content providers to identify users (if not authenticate, especially within the context of enforcing electronic payment schemes) and to retrieve statistical information for accounting purposes, as far as content and network usage are concerned. This memo describes the framework for specifying the Authorization, Authentication and Accounting (AAA) capabilities that could be activated within the context of the deployment and the operation of IP multicast-based services. This framework addresses the requirements presented in "Requirements for Accounting, Authentication and Authorization in Well Managed IP Multicasting Services" [I-D.ietf-mboned-maccnt-req]. The memo provides a basic AAA enabled model as well as an extended fully enabled model with resource and admission control coordination. |
| | Authentication/Confidentiality for OSPFv2 |
| |
|
This document describes means and mechanisms to provide authentication/confidentiality to OSPFv2 using IPsec (IP Security). |
| | Preference Level based Binding Table |
| |
|
[fcfs] proposes a simple preference scheme to resolve binding entry collisions (same l3 address, different anchors): it keeps the first entry and rejects any others. However, there are cases where keeping the first entry is not the best choice, and others cases where it is bogus. This draft analyses what are these cases, and proposes a different algorithm (preference based) to fix the problem. |
| | SAFE (Server-side Asynchronous Framework Execution) Scripting Method |
| |
|
SAFE Scripting Method is a model for allowing application interactivity in email while simultaneously elminating security vulnerabilities associated with client-side scripting. |
| | Manifests for the Resource Public Key Infrastructure |
| |
|
This document defines a "manifest" for use in the Resource Public Key Infrastructure. A manifest is a signed object that contains a listing of all the signed objects in the repository publication point associated with an authority responsible for publishing in the repository. For each certificate, or other forms of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object, and a hash of the file content. Manifests are intended to expose potential attacks against relying parties of the Resource Public Key Infrastructure, such as a man-in-the middle attack of withholding repository data from relying party access, or replaying stale repository data to a relying party's access request. |
| | A Profile for Resource Certificate Repository Structure |
| |
|
This document defines a profile for the structure of repository publication points that contain X.509 / PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile contains the proposed object naming scheme, the contents of repository publication points, the contents of publication point manifests and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and facilitate certification path construction. |
03/08/2009
| |
|
| |
| | AS-wide Unique BGP Identifier for BGP-4 |
| |
|
To accommodate situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet unsigned, non-zero integer, and relaxes the "uniqueness" requirement so that only AS-wide uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issue. |
| | Advertisement of Multiple Paths in BGP |
| |
|
In this document we propose a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a path identifier in addition to the address prefix. |
| | Extensible Markup Language Evidence Record Syntax |
| |
| | draft-ietf-ltans-xmlers-04.txt |
| | Date: |
03/08/2009 |
| | Authors: |
A. Jerman Blazic, Svetlana Saljic, Tobias Gondrom |
| | Working Group: |
Long-Term Archive and Notary Services (ltans) |
| | Formats: |
txt |
|
In many scenarios, users must be able to demonstrate the (time) existence, integrity and validity of data including signed data for long or undetermined period of time. This document specifies XML syntax and processing rules for creating evidence for long-term non- repudiation of existence of data. ERS-XML incorporates alternative syntax and processing rules to ASN.1 ERS syntax by using XML language. |
| | Overview of the Internet Multicast Addressing Architecture |
| |
|
The lack of up-to-date documentation on IP multicast address allocation and assignment procedures has caused a great deal of confusion. To clarify the situation, this memo describes the allocation and assignment techniques and mechanisms currently (as of this writing) in use. |
| | Extending ICMP for Interface and Next-hop Identification |
| |
|
This memo defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used identify any combination of the following: the IP interface upon which a datagram arrived, the sub-IP component of an IP interface upon which a datagram arrived, the IP interface through which the datagram would have been for forwarded had it been forwardable, the IP next hop to which the datagram would have been forwarded. Devices can use this ICMP extension to identify interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name and MTU. ICMP-aware devices can use these extensions to identify both numbered and unnumbered interfaces. |
| | The Minger Email Address Verification Protocol |
| |
|
This document describes the Minger protocol. Minger is a protocol which allows a mail handling entity to query a remote service and ask the question "do you accept mail for this email address?" It includes security in the form of a hashed shared secret but can also be used anonymously if desired. |
| | Metering and marking behaviour of PCN-nodes |
| |
|
The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain, in a simple, scalable, and robust fashion. This document defines the two metering and marking behaviours of PCN-nodes. Threshold-metering and -marking marks all PCN-packets if the rate of PCN-traffic is greater than a configured rate ("PCN-threshold-rate"). Excess- traffic-metering and -marking marks a proportion of PCN-packets, such that the amount marked equals the rate of PCN-traffic in excess of a configured rate ("PCN-excess-rate"). The level of marking allows PCN-boundary-nodes to make decisions about whether to admit or terminate PCN-flows. |
02/08/2009
| |
|
| |
| | Using EAP-GTC for Simple User Authentication in IKEv2 |
| |
|
Despite many years of effort, simple username-password authentication is still prevalent. In many cases a password is the only credential available to the end user. IKEv2 uses EAP as a sub-protocol for user authentication. This provides a well-specified and extensible architecture. To this day EAP does not provide a simple password- based authentication method. The only existing password authentication methods either require the peer to know the password in advance (EAP-MD5), or are needlessly complex when used within IKEv2 (e.g. PEAP). This document codifies the common practice of using EAP-GTC for this type of authentication, with the goal of achieving maximum interoperability. The various security issues are extensively analyzed. |
| | Deprecate DES support for Kerberos |
| |
|
A long long time ago DES was standardized. Some 30 years later (2003) is was withdrawn as a standard by NIST, today 6 years later, its time for DES to finally die. By 2008 it was possible to brute force DES keys in 6.4 days using less than USD 10k worth of hardware. So by 2008 DES had passed its sell-by date. Use in Kerberos should therefore stop.1. Requirements Notation |
|
