Cryptographic Authentication
This document describes the authentication of Intermediate System to
Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed
Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as
found in RFC 2104. IS-IS is specified in International Standards
Organization (ISO) 10589, with extensions to support Internet Protocol
version 4 (IPv4) described in RFC 1195. The base specification includes
an authentication mechanism that allows for multiple authentication
algorithms. The base specification only specifies the algorithm for
cleartext passwords.
This document proposes an extension to that specification that allows
the use of the HMAC-MD5 authentication algorithm to be used in
conjunction with the existing authentication mechanisms. This memo
provides information for the Internet community.
3566 Frankel Sep 2003 The AES-XCBC-MAC-96 Algorithm
and Its Use With IPsec
A Message Authentication Code (MAC) is a key-dependent one way hash
function. One popular way to construct a MAC algorithm is to use a
block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of
operation. The classic CBC-MAC algorithm, while secure for messages of
a pre-selected fixed length, has been shown to be insecure across
messages of varying lengths such as the type found in typical IP
datagrams. This memo specifies the use of AES in CBC mode with a set of
extensions to overcome this limitation. This new algorithm is named
AES-XCBC-MAC-96. [STANDARDS TRACK]
3565 Schaad Jul 2003 Use of the Advanced Encryption
Standard (AES) Encryption
Algorithm in Cryptographic
Message Syntax (CMS)
This document specifies the conventions for using the Advanced
Encryption Standard (AES) algorithm for encryption with the
Cryptographic Message Syntax (CMS). [STANDARDS TRACK]
3564 Le Faucheur Jul 2003 Requirements for Support of
Differentiated Services-aware
MPLS Traffic Engineering
This document presents Service Provider requirements for support of
Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering (DS-
TE).
Its objective is to provide guidance for the definition, selection and
specification of a technical solution addressing these requirements.
Specification for this solution itself is outside the scope of this
document.
A problem statement is first provided. Then, the document describes
example applications scenarios identified by Service Providers where
existing MPLS Traffic Engineering mechanisms fall short and
Diff-Serv-aware Traffic Engineering can address the needs. The detailed
requirements that need to be addressed by the technical solution are
also reviewed. Finally, the document identifies the evaluation criteria
that should be considered for selection and definition of the technical
solution. This memo provides information for the Internet community.
3563 Zinin Jul 2003 Cooperative Agreement Between
the ISOC/IETF and ISO/IEC
Joint Technical Committee
1/Sub Committee 6 (JTC1/SC6)
on IS-IS Routing Protocol
Development
This document contains the text of the agreement signed between
ISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of the
IS-IS routing protocol. The agreement includes definitions of the
related work scopes for the two organizations, request for creation and
maintenance of an IS-IS registry by IANA, as well as collaboration
guidelines. This memo provides information for the Internet community.
3562 Leech Jul 2003 Key Management Considerations
for the TCP MD5 Signature
Option
The TCP MD5 Signature Option (RFC 2385), used predominantly by BGP, has
seen significant deployment in critical areas of Internet
infrastructure. The security of this option relies heavily on the
quality of the keying material used to compute the MD5 signature. This
document addresses the security requirements of that keying material.
This memo provides information for the Internet community.
3561 Perkins Jul 2003 Ad hoc On-Demand Distance
Vector (AODV) Routing
The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended
for use by mobile nodes in an ad hoc network. It offers quick
adaptation to dynamic link conditions, low processing and memory
overhead, low network utilization, and determines unicast routes to
destinations within the ad hoc network. It uses destination sequence
numbers to ensure loop freedom at all times (even in the face of
anomalous delivery of routing control messages), avoiding problems (such
as "counting to infinity") associated with classical distance vector
protocols. This memo defines an Experimental Protocol for the Internet
community.
3560 Housley Jul 2003 Use of the RSAES-OAEP Key
Transport Algorithm in
the Cryptographic Message
Syntax (CMS)
This document describes the conventions for using the RSAES-OAEP key
transport algorithm with the Cryptographic Message Syntax (CMS). The
CMS specifies the enveloped-data content type, which consists of an
encrypted content and encrypted content-encryption keys for one or more
recipients. The RSAES-OAEP key transport algorithm can be used to
encrypt content-encryption keys for intended recipients. [STANDARDS
TRACK]
3559 Thaler Jun 2003 Multicast Address Allocation
MIB
This memo 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 multicast
address allocation. [STANDARDS TRACK]
3558 Li Jul 2003 RTP Payload Format for
Enhanced Variable Rate Codecs
(EVRC) and Selectable Mode
Vocoders (SMV)
This document describes the RTP payload format for Enhanced Variable
Rate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech. Two
sub-formats are specified for different application scenarios. A
bundled/interleaved format is included to reduce the effect of packet
loss on speech quality and amortize the overhead of the RTP header over
more than one speech frame. A non-bundled format is also supported for
conversational applications. [STANDARDS TRACK]
3557 Xie, Ed. Jul 2003 RTP Payload Format for
European Telecommunications
Standards Institute (ETSI)
European Standard ES 201 108
Distributed Speech Recognition
Encoding
This document specifies an RTP payload format for encapsulating European
Telecommunications Standards Institute (ETSI) European Standard (ES) 201
108 front-end signal processing feature streams for distributed speech
recognition (DSR) systems. [STANDARDS TRACK]
3556 Casner Jul 2003 Session Description Protocol
(SDP) Bandwidth Modifiers
for RTP Control Protocol
(RTCP) Bandwidth
This document defines an extension to the Session Description Protocol
(SDP) to specify two additional modifiers for the bandwidth attribute.
These modifiers may be used to specify the bandwidth allowed for RTP
Control Protocol (RTCP) packets in a Real-time Transport Protocol (RTP)
session. [STANDARDS TRACK]
3555 Casner Jul 2003 MIME Type Registration of RTP
Payload Formats
This document defines the procedure to register RTP Payload Formats as
audio, video or other MIME subtype names. This is useful in a text-
based format or control protocol to identify the type of an RTP
transmission. This document also registers all the RTP payload formats
defined in the RTP Profile for Audio and Video Conferences as MIME
subtypes. Some of these may also be used for transfer modes other than
RTP. [STANDARDS TRACK]
3554 Bellovin Jul 2003 On the Use of Stream Control
Transmission Protocol (SCTP)
with IPsec
This document describes functional requirements for IPsec (RFC 2401) and
Internet Key Exchange (IKE) (RFC 2409) to facilitate their use in
securing SCTP (RFC 2960) traffic. [STANDARDS TRACK]
3553 Mealling Jun 2003 An IETF URN Sub-namespace for
Registered Protocol Parameters
This document describes a new sub-delegation for the ’ietf’ URN
namespace for registered protocol items. The ’ietf’ URN namespace is
defined in RFC 2648 as a root for persistent URIs that refer to IETF-
defined resources. This document specifies an Internet Best Current
Practices for the Internet Community, and requests discussion and
suggestions for improvements.
3552 Rescorla Jul 2003 Guidelines for Writing RFC
Text on Security
Considerations
All RFCs are required to have a Security Considerations section.
Historically, such sections have been relatively weak. This document
provides guidelines to RFC authors on how to write a good Security
Considerations section. This document specifies an Internet Best
Current Practices for the Internet Community, and requests discussion
and suggestions for improvements.
3551 Schulzrinne Jul 2003 RTP Profile for Audio and
Video Conferences with Minimal
Control
This document describes a profile called "RTP/AVP" for the use of the
real-time transport protocol (RTP), version 2, and the associated
control protocol, RTCP, within audio and video multiparticipant
conferences with minimal control. It provides interpretations of
generic fields within the RTP specification suitable for audio and video
conferences. In particular, this document defines a set of default
mappings from payload type numbers to encodings.
This document also describes how audio and video data may be carried
within RTP. It defines a set of standard encodings and their names when
used within RTP. The descriptions provide pointers to reference
implementations and the detailed standards. This document is meant as
an aid for implementors of audio, video and other real-time multimedia
applications.
This memorandum obsoletes RFC 1890. It is mostly backwards-compatible
except for functions removed because two interoperable implementations
were not found. The additions to RFC 1890 codify existing practice in
the use of payload formats under this profile and include new payload
formats defined since RFC 1890 was published. [STANDARDS TRACK]
3550 Schulzrinne Jul 2003 RTP: A Transport Protocol for
Real-Time Applications
This memorandum describes RTP, the real-time transport protocol. RTP
provides end-to-end network transport functions suitable for
applications transmitting real-time data, such as audio, video or
simulation data, over multicast or unicast network services. RTP does
not address resource reservation and does not guarantee quality-of-
service for real-time services. The data transport is augmented by a
control protocol (RTCP) to allow monitoring of the data delivery in a
manner scalable to large multicast networks, and to provide minimal
control and identification functionality. RTP and RTCP are designed to
be independent of the underlying transport and network layers. The
protocol supports the use of RTP-level translators and mixers.
Most of the text in this memorandum is identical to RFC 1889 which it
obsoletes. There are no changes in the packet formats on the wire, only
changes to the rules and algorithms governing how the protocol is used.
The biggest change is an enhancement to the scalable timer algorithm for
calculating when to send RTCP packets in order to minimize transmission
in excess of the intended rate when many participants join a session
simultaneously. [STANDARDS TRACK]
3549 Salim Jul 2003 Linux Netlink as an IP
Services Protocol
This document describes Linux Netlink, which is used in Linux both as an
intra-kernel messaging system as well as between kernel and user space.
The focus of this document is to describe Netlink’s functionality as a
protocol between a Forwarding Engine Component (FEC) and a Control Plane
Component (CPC), the two components that define an IP service. As a
result of this focus, this document ignores other uses of Netlink,
including its use as a intra-kernel messaging system, as an inter-
process communication scheme (IPC), or as a configuration tool for other
non-networking or non-IP network services (such as decnet, etc.).
This document is intended as informational in the context of prior art
for the ForCES IETF working group. This memo provides information for
the Internet community.
3548 Josefsson Jul 2003 The Base16, Base32, and Base64
Data Encodings
This document describes the commonly used base 64, base 32, and base 16
encoding schemes. It also discusses the use of line-feeds in encoded
data, use of padding in encoded data, use of non-alphabet characters in
encoded data, and use of different encoding alphabets. This memo
provides information for the Internet community.
3547 Baugher Jul 2003 The Group Domain of
Interpretation
This document presents an ISAMKP Domain of Interpretation (DOI) for
group key management to support secure group communications. The GDOI
manages group security associations, which are used by IPSEC and
potentially other data security protocols running at the IP or
application layers. These security associations protect one or more
key-encrypting keys, traffic-encrypting keys, or data shared by group
members. [STANDARDS TRACK]
3546 Blake-Wilson Jun 2003 Transport Layer Security (TLS)
Extensions
This document describes extensions that may be used to add functionality
to Transport Layer Security (TLS). It provides both generic extension
mechanisms for the TLS handshake client and server hellos, and specific
extensions using these generic mechanisms.
The extensions may be used by TLS clients and servers. The extensions
are backwards compatible - communication is possible between TLS 1.0
clients that support the extensions and TLS 1.0 servers that do not
support the extensions, and vice versa. [STANDARDS TRACK]
3545 Koren Jul 2003 Enhanced Compressed RTP (CRTP)
for Links with High Delay,
Packet Loss and Reordering
This document describes a header compression scheme for point to point
links with packet loss and long delays. It is based on Compressed
Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression
described in RFC 2508. CRTP does not perform well on such links: packet
loss results in context corruption and due to the long delay, many more
packets are discarded before the context is repaired. To correct the
behavior of CRTP over such links, a few extensions to the protocol are
specified here. The extensions aim to reduce context corruption by
changing the way the compressor updates the context at the decompressor:
updates are repeated and include updates to full and differential
context parameters. With these extensions, CRTP performs well over
links with packet loss, packet reordering and long delays. [STANDARDS
TRACK]
3544 Koren Jul 2003 IP Header Compression over PPP
This document describes an option for negotiating the use of header
compression on IP datagrams transmitted over the Point-to-Point Protocol
(RFC 1661). It defines extensions to the PPP Control Protocols for IPv4
and IPv6 (RFC 1332, RFC 2472). Header compression may be applied to
IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport
protocols as specified in RFC 2507, RFC 2508 and RFC 3545. [STANDARDS
TRACK]
3543 Glass Aug 2003 Registration Revocation in
Mobile IPv4
This document defines a Mobile IPv4 Registration Revocation mechanism
whereby a mobility agent involved in providing Mobile IP services to a
mobile node can notify the other mobility agent providing Mobile IP
services to the same mobile node of the termination of this
registration. The mechanism is also usable by a home agent to notify a
co-located mobile node of the termination of its binding as well.
Moreover, the mechanism provides for this notification to be
acknowledged. A signaling mechanism already defined by the Mobile IPv4
protocol is leveraged as a way to inform a mobile node of the revocation
of its binding. [STANDARDS TRACK]
3542 Stevens May 2003 Advanced Sockets Application
Program Interface (API) for
IPv6
This document provides sockets Application Program Interface (API) to
support "advanced" IPv6 applications, as a supplement to a separate
specification, RFC 3493. The expected applications include Ping,
Traceroute, routing daemons and the like, which typically use raw
sockets to access IPv6 or ICMPv6 header fields. This document proposes
some portable interfaces for applications that use raw sockets under
IPv6. There are other features of IPv6 that some applications will need
to access: interface identification (specifying the outgoing interface
and determining the incoming interface), IPv6 extension headers, and
path Maximum Transmission Unit (MTU) information. This document
provides API access to these features too. Additionally, some extended
interfaces to libraries for the "r" commands are defined. The extension
will provide better backward compatibility to existing implementations
that are not IPv6-capable. This memo provides information for the
Internet community.
3541 Walsh May 2003 A Uniform Resource Name (URN)
Namespace for the Web3D
Consortium (Web3D)
This document describes a Uniform Resource Name (URN) namespace for the
Web3D Consortium (Web3D) for naming persistent resources such as
technical documents and specifications, Virtual Reality Modeling
Language (VRML) and Extensible 3D (X3D) files and resources, Extensible
Markup Language (XML) Document Type Definitions (DTDs), XML Schemas,
namespaces, style sheets, media assets, and other resources produced or
managed by Web3D. This memo provides information for the Internet
community.
3540 Spring Jun 2003 Robust Explicit Congestion
Notification (ECN)
Signaling with Nonces
This note describes the Explicit Congestion Notification (ECN)-nonce, an
optional addition to ECN that protects against accidental or malicious
concealment of marked packets from the TCP sender. It improves the
robustness of congestion control by preventing receivers from exploiting
ECN to gain an unfair share of network bandwidth. The ECN-nonce uses
the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP
header, and requires a flag in the TCP header. It is computationally
efficient for both routers and hosts. This memo defines an Experimental
Protocol for the Internet community.
3539 Aboba Jun 2003 Authentication, Authorization
and Accounting (AAA) Transport
Profile
This document discusses transport issues that arise within protocols for
Authentication, Authorization and Accounting (AAA). It also provides
recommendations on the use of transport by AAA protocols. This includes
usage of standards-track RFCs as well as experimental proposals.
[STANDARDS TRACK]
3538 Kawatsura Jun 2003 Secure Electronic Transaction
(SET) Supplement for the v1.0
Internet Open Trading Protocol
(IOTP)
This document describes detailed Input/Output parameters for the
Internet Open Trading Protocol (IOTP) Payment Application Programming
Interface (API). It also describes procedures in the Payment Bridge for
the use of SET (SET Secure Electronic Transaction) as the payment
protocol within Version 1.0 of the IOTP. This memo provides information
for the Internet community.
3537 Schaad May 2003 Wrapping a Hashed Message
Authentication Code (HMAC) key
with a Triple-Data Encryption
Standard (DES) Key or an
Advanced Encryption Standard