Generic String Encoding Rules (GSER) for ASN.1 Types
RFC 3641
| Document | Type |
RFC
- Proposed Standard
(October 2003)
Updated by RFC 4792
Was
draft-legg-ldap-gser
(individual in app area)
|
|
|---|---|---|---|
| Author | Steven Legg | ||
| Last updated | 2018-07-18 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| IESG | Responsible AD | Ted Hardie | |
| Send notices to | (None) |
RFC 3641
Internet Engineering Task Force (IETF) R. Stewart
Request for Comments: 9260 Netflix, Inc.
Obsoletes: 4460, 4960, 6096, 7053, 8540 M. Tüxen
Category: Standards Track Münster Univ. of Appl. Sciences
ISSN: 2070-1721 K. Nielsen
Kamstrup A/S
June 2022
Stream Control Transmission Protocol
Abstract
This document describes the Stream Control Transmission Protocol
(SCTP) and obsoletes RFC 4960. It incorporates the specification of
the chunk flags registry from RFC 6096 and the specification of the I
bit of DATA chunks from RFC 7053. Therefore, RFCs 6096 and 7053 are
also obsoleted by this document. In addition, RFCs 4460 and 8540,
which describe errata for SCTP, are obsoleted by this document.
SCTP was originally designed to transport Public Switched Telephone
Network (PSTN) signaling messages over IP networks. It is also
suited to be used for other applications, for example, WebRTC.
SCTP is a reliable transport protocol operating on top of a
connectionless packet network, such as IP. It offers the following
services to its users:
* acknowledged error-free, non-duplicated transfer of user data,
* data fragmentation to conform to discovered Path Maximum
Transmission Unit (PMTU) size,
* sequenced delivery of user messages within multiple streams, with
an option for order-of-arrival delivery of individual user
messages,
* optional bundling of multiple user messages into a single SCTP
packet, and
* network-level fault tolerance through supporting of multi-homing
at either or both ends of an association.
The design of SCTP includes appropriate congestion avoidance behavior
and resistance to flooding and masquerade attacks.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9260.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction
1.1. Motivation
1.2. Architectural View of SCTP
1.3. Key Terms
1.4. Abbreviations
1.5. Functional View of SCTP
1.5.1. Association Startup and Takedown
1.5.2. Sequenced Delivery within Streams
1.5.3. User Data Fragmentation
1.5.4. Acknowledgement and Congestion Avoidance
1.5.5. Chunk Bundling
1.5.6. Packet Validation
1.5.7. Path Management
1.6. Serial Number Arithmetic
1.7. Changes from RFC 4960
2. Conventions
3. SCTP Packet Format
3.1. SCTP Common Header Field Descriptions
3.2. Chunk Field Descriptions
3.2.1. Optional/Variable-Length Parameter Format
3.2.2. Reporting of Unrecognized Parameters
3.3. SCTP Chunk Definitions
3.3.1. Payload Data (DATA) (0)
3.3.2. Initiation (INIT) (1)
3.3.2.1. Optional or Variable-Length Parameters in INIT
chunks
3.3.3. Initiation Acknowledgement (INIT ACK) (2)
3.3.3.1. Optional or Variable-Length Parameters in INIT ACK
Chunks
3.3.4. Selective Acknowledgement (SACK) (3)
3.3.5. Heartbeat Request (HEARTBEAT) (4)
3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5)
3.3.7. Abort Association (ABORT) (6)
3.3.8. Shutdown Association (SHUTDOWN) (7)
3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8)
3.3.10. Operation Error (ERROR) (9)
3.3.10.1. Invalid Stream Identifier (1)
3.3.10.2. Missing Mandatory Parameter (2)
3.3.10.3. Stale Cookie (3)
3.3.10.4. Out of Resource (4)
3.3.10.5. Unresolvable Address (5)
3.3.10.6. Unrecognized Chunk Type (6)
3.3.10.7. Invalid Mandatory Parameter (7)
3.3.10.8. Unrecognized Parameters (8)
3.3.10.9. No User Data (9)
3.3.10.10. Cookie Received While Shutting Down (10)
3.3.10.11. Restart of an Association with New Addresses (11)
3.3.10.12. User-Initiated Abort (12)
3.3.10.13. Protocol Violation (13)
3.3.11. Cookie Echo (COOKIE ECHO) (10)
3.3.12. Cookie Acknowledgement (COOKIE ACK) (11)
3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14)
4. SCTP Association State Diagram
5. Association Initialization
5.1. Normal Establishment of an Association
5.1.1. Handle Stream Parameters
5.1.2. Handle Address Parameters
5.1.3. Generating State Cookie
5.1.4. State Cookie Processing
5.1.5. State Cookie Authentication
5.1.6. An Example of Normal Association Establishment
5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO,
and COOKIE ACK Chunks
5.2.1. INIT Chunk Received in COOKIE-WAIT or COOKIE-ECHOED
State (Item B)
5.2.2. Unexpected INIT Chunk in States Other than CLOSED,
COOKIE-ECHOED, COOKIE-WAIT, and SHUTDOWN-ACK-SENT
5.2.3. Unexpected INIT ACK Chunk
5.2.4. Handle a COOKIE ECHO Chunk When a TCB Exists
5.2.4.1. An Example of an Association Restart
5.2.5. Handle Duplicate COOKIE ACK Chunk
5.2.6. Handle Stale Cookie Error
5.3. Other Initialization Issues
5.3.1. Selection of Tag Value
5.4. Path Verification
6. User Data Transfer
6.1. Transmission of DATA Chunks
6.2. Acknowledgement on Reception of DATA Chunks
6.2.1. Processing a Received SACK Chunk
6.3. Management of Retransmission Timer
6.3.1. RTO Calculation
6.3.2. Retransmission Timer Rules
6.3.3. Handle T3-rtx Expiration
6.4. Multi-Homed SCTP Endpoints
6.4.1. Failover from an Inactive Destination Address
6.5. Stream Identifier and Stream Sequence Number
6.6. Ordered and Unordered Delivery
6.7. Report Gaps in Received DATA TSNs
6.8. CRC32c Checksum Calculation
6.9. Fragmentation and Reassembly
6.10. Bundling
7. Congestion Control
7.1. SCTP Differences from TCP Congestion Control
7.2. SCTP Slow-Start and Congestion Avoidance
7.2.1. Slow-Start
7.2.2. Congestion Avoidance
7.2.3. Congestion Control
7.2.4. Fast Retransmit on Gap Reports
7.2.5. Reinitialization
7.2.5.1. Change of Differentiated Services Code Points
7.2.5.2. Change of Routes
7.3. PMTU Discovery
8. Fault Management
8.1. Endpoint Failure Detection
8.2. Path Failure Detection
8.3. Path Heartbeat
8.4. Handle "Out of the Blue" Packets
8.5. Verification Tag
8.5.1. Exceptions in Verification Tag Rules
9. Termination of Association
9.1. Abort of an Association
9.2. Shutdown of an Association
10. ICMP Handling
11. Interface with Upper Layer
11.1. ULP-to-SCTP
11.1.1. Initialize
11.1.2. Associate
11.1.3. Shutdown
11.1.4. Abort
11.1.5. Send
11.1.6. Set Primary
11.1.7. Receive
11.1.8. Status
11.1.9. Change Heartbeat
11.1.10. Request Heartbeat
11.1.11. Get SRTT Report
11.1.12. Set Failure Threshold
11.1.13. Set Protocol Parameters
11.1.14. Receive Unsent Message
11.1.15. Receive Unacknowledged Message
11.1.16. Destroy SCTP Instance
11.2. SCTP-to-ULP
11.2.1. DATA ARRIVE Notification
11.2.2. SEND FAILURE Notification
11.2.3. NETWORK STATUS CHANGE Notification
11.2.4. COMMUNICATION UP Notification
11.2.5. COMMUNICATION LOST Notification
11.2.6. COMMUNICATION ERROR Notification
11.2.7. RESTART Notification
11.2.8. SHUTDOWN COMPLETE Notification
12. Security Considerations
12.1. Security Objectives
12.2. SCTP Responses to Potential Threats
12.2.1. Countering Insider Attacks
12.2.2. Protecting against Data Corruption in the Network
12.2.3. Protecting Confidentiality
12.2.4. Protecting against Blind Denial-of-Service Attacks
12.2.4.1. Flooding
12.2.4.2. Blind Masquerade
12.2.4.3. Improper Monopolization of Services
12.3. SCTP Interactions with Firewalls
12.4. Protection of Non-SCTP-capable Hosts
13. Network Management Considerations
14. Recommended Transmission Control Block (TCB) Parameters
14.1. Parameters Necessary for the SCTP Instance
14.2. Parameters Necessary per Association (i.e., the TCB)
14.3. Per Transport Address Data
14.4. General Parameters Needed
15. IANA Considerations
15.1. IETF-Defined Chunk Extension
15.2. IETF-Defined Chunk Flags Registration
15.3. IETF-Defined Chunk Parameter Extension
15.4. IETF-Defined Additional Error Causes
15.5. Payload Protocol Identifiers
15.6. Port Numbers Registry
16. Suggested SCTP Protocol Parameter Values
17. References
17.1. Normative References
17.2. Informative References
Appendix A. CRC32c Checksum Calculation
Acknowledgements
Authors' Addresses
1. Introduction
This section explains the reasoning behind the development of the
Stream Control Transmission Protocol (SCTP), the services it offers,
and the basic concepts needed to understand the detailed description
of the protocol.
This document obsoletes [RFC4960]. In addition to that, it
incorporates the specification of the chunk flags registry from
[RFC6096] and the specification of the I bit of DATA chunks from
[RFC7053]. Therefore, [RFC6096] and [RFC7053] are also obsoleted by
this document.
1.1. Motivation
TCP [RFC0793] has performed immense service as the primary means of
reliable data transfer in IP networks. However, an increasing number
of recent applications have found TCP too limiting and have
incorporated their own reliable data transfer protocol on top of UDP
[RFC0768]. The limitations that users have wished to bypass include
the following:
* TCP provides both reliable data transfer and strict order-of-
transmission delivery of data. Some applications need reliable
transfer without sequence maintenance, while others would be
satisfied with partial ordering of the data. In both of these
cases, the head-of-line blocking offered by TCP causes unnecessary
delay.
* The stream-oriented nature of TCP is often an inconvenience.
Applications add their own record marking to delineate their
messages and make explicit use of the push facility to ensure that
a complete message is transferred in a reasonable time.
* The limited scope of TCP sockets complicates the task of providing
highly available data transfer capability using multi-homed hosts.
* TCP is relatively vulnerable to denial-of-service attacks, such as
SYN attacks.
Transport of PSTN signaling across the IP network is an application
for which all of these limitations of TCP are relevant. While this
application directly motivated the development of SCTP, other
applications might find SCTP a good match to their requirements. One
example of this is the use of data channels in the WebRTC
infrastructure.
1.2. Architectural View of SCTP
SCTP is viewed as a layer between the SCTP user application ("SCTP
user" for short) and a connectionless packet network service, such as
IP. The remainder of this document assumes SCTP runs on top of IP.
The basic service offered by SCTP is the reliable transfer of user
messages between peer SCTP users. It performs this service within
the context of an association between two SCTP endpoints. Section 11
of this document sketches the API that exists at the boundary between
SCTP and the SCTP upper layers.
SCTP is connection oriented in nature, but the SCTP association is a
broader concept than the TCP connection. SCTP provides the means for
each SCTP endpoint (Section 1.3) to provide the other endpoint
(during association startup) with a list of transport addresses
(i.e., multiple IP addresses in combination with an SCTP port)
through which that endpoint can be reached and from which it will
originate SCTP packets. The association spans transfers over all of
the possible source/destination combinations that can be generated
from each endpoint's lists.
_____________ _____________
| SCTP User | | SCTP User |
| Application | | Application |
|-------------| |-------------|
| SCTP | | SCTP |
| Transport | | Transport |
| Service | | Service |
|-------------| |-------------|
| |One or more ---- One or more| |
| IP Network |IP address \/ IP address| IP Network |
| Service |appearances /\ appearances| Service |
|_____________| ---- |_____________|
SCTP Node A |<-------- Network transport ------->| SCTP Node B
Figure 1: An SCTP Association
In addition to encapsulating SCTP packets in IPv4 or IPv6, it is also
possible to encapsulate SCTP packets in UDP as specified in [RFC6951]
or encapsulate them in DTLS as specified in [RFC8261].
1.3. Key Terms
Some of the language used to describe SCTP has been introduced in the
previous sections. This section provides a consolidated list of the
key terms and their definitions.
Active Destination Transport Address: A transport address on a peer
endpoint that a transmitting endpoint considers available for
receiving user messages.
Association Maximum DATA Chunk Size (AMDCS): The smallest Path
Maximum DATA Chunk Size (PMDCS) of all destination addresses.
Bundling of Chunks: An optional multiplexing operation, whereby more
than one chunk can be carried in the same SCTP packet.
Bundling of User Messages: An optional multiplexing operation,
whereby more than one user message can be carried in the same SCTP
packet. Each user message occupies its own DATA chunk.
Chunk: A unit of information within an SCTP packet, consisting of a
chunk header and chunk-specific content.
Congestion Window (cwnd): An SCTP variable that limits outstanding
data, in number of bytes, that a sender can send to a particular
destination transport address before receiving an acknowledgement.
Control Chunk: A chunk not being used for transmitting user data,
i.e., every chunk that is not a DATA chunk.
Cumulative TSN Ack Point: The Transmission Sequence Number (TSN) of
the last DATA chunk acknowledged via the Cumulative TSN Ack field
of a SACK chunk.
Flightsize: The number of bytes of outstanding data to a particular
destination transport address at any given time.
Idle Destination Address: An address that has not had user messages
sent to it within some length of time, normally the 'HB.interval'
or greater.
Inactive Destination Transport Address: An address that is
considered inactive due to errors and unavailable to transport
user messages.
Message (or User Message): Data submitted to SCTP by the Upper-Layer
Protocol (ULP).
Network Byte Order: Most significant byte first, a.k.a., big endian.
Ordered Message: A user message that is delivered in order with
respect to all previous user messages sent within the stream on
which the message was sent.
Outstanding Data (or Data Outstanding or Data In Flight): The total
size of the DATA chunks associated with outstanding TSNs. A
retransmitted DATA chunk is counted once in outstanding data. A
DATA chunk that is classified as lost but that has not yet been
retransmitted is not in outstanding data.
Outstanding TSN (at an SCTP Endpoint): A TSN (and the associated
DATA chunk) that has been sent by the endpoint but for which it
has not yet received an acknowledgement.
"Out of the Blue" (OOTB) Packet: A correctly formed packet, for
which the receiver cannot identify the association it belongs to.
See Section 8.4.
Path: The route taken by the SCTP packets sent by one SCTP endpoint
to a specific destination transport address of its peer SCTP
endpoint. Sending to different destination transport addresses
does not necessarily guarantee getting separate paths. Within
this specification, a path is identified by the destination
transport address, since the routing is assumed to be stable.
This includes, in particular, the source address being selected
when sending packets to the destination address.
Path Maximum DATA Chunk Size (PMDCS): The maximum size (including
the DATA chunk header) of a DATA chunk that fits into an SCTP
packet not exceeding the PMTU of a particular destination address.
Path Maximum Transmission Unit (PMTU): The maximum size (including
the SCTP common header and all chunks including their paddings) of
an SCTP packet that can be sent to a particular destination
address without using IP-level fragmentation.
Primary Path: The destination and source address that will be put
into a packet outbound to the peer endpoint by default. The
definition includes the source address since an implementation MAY
wish to specify both destination and source address to better
control the return path taken by reply chunks and on which
interface the packet is transmitted when the data sender is multi-
homed.
Receiver Window (rwnd): An SCTP variable a data sender uses to store
the most recently calculated receiver window of its peer, in
number of bytes. This gives the sender an indication of the space
available in the receiver's inbound buffer.
SCTP Association: A protocol relationship between SCTP endpoints,
composed of the two SCTP endpoints and protocol state information,
including Verification Tags and the currently active set of
Transmission Sequence Numbers (TSNs), etc. An association can be
uniquely identified by the transport addresses used by the
endpoints in the association. Two SCTP endpoints MUST NOT have
more than one SCTP association between them at any given time.
SCTP Endpoint: The logical sender/receiver of SCTP packets. On a
multi-homed host, an SCTP endpoint is represented to its peers as
a combination of a set of eligible destination transport addresses
to which SCTP packets can be sent and a set of eligible source
transport addresses from which SCTP packets can be received. All
transport addresses used by an SCTP endpoint MUST use the same
port number but can use multiple IP addresses. A transport
address used by an SCTP endpoint MUST NOT be used by another SCTP
endpoint. In other words, a transport address is unique to an
SCTP endpoint.
SCTP Packet (or Packet): The unit of data delivery across the
interface between SCTP and the connectionless packet network
(e.g., IP). An SCTP packet includes the common SCTP header,
possible SCTP control chunks, and user data encapsulated within
SCTP DATA chunks.
SCTP User Application (or SCTP User): The logical higher-layer
application entity that uses the services of SCTP, also called the
Upper-Layer Protocol (ULP).
Slow-Start Threshold (ssthresh): An SCTP variable. This is the
threshold that the endpoint will use to determine whether to
perform slow-start or congestion avoidance on a particular
destination transport address. Ssthresh is in number of bytes.
State Cookie: A container of all information needed to establish an
association.
Stream: A unidirectional logical channel established from one to
another associated SCTP endpoint, within which all user messages
are delivered in sequence, except for those submitted to the
unordered delivery service.
Note: The relationship between stream numbers in opposite
directions is strictly a matter of how the applications use them.
It is the responsibility of the SCTP user to create and manage
these correlations if they are so desired.
Stream Sequence Number: A 16-bit sequence number used internally by
SCTP to ensure sequenced delivery of the user messages within a
given stream. One Stream Sequence Number is attached to each
ordered user message.
Tie-Tags: Two 32-bit random numbers that together make a 64-bit
nonce. These tags are used within a State Cookie and TCB so that
a newly restarting association can be linked to the original
association within the endpoint that did not restart and yet not
reveal the true Verification Tags of an existing association.
Transmission Control Block (TCB): An internal data structure created
by an SCTP endpoint for each of its existing SCTP associations to
other SCTP endpoints. TCB contains all the status and operational
information for the endpoint to maintain and manage the
corresponding association.
Transmission Sequence Number (TSN): A 32-bit sequence number used
internally by SCTP. One TSN is attached to each chunk containing
user data to permit the receiving SCTP endpoint to acknowledge its
receipt and detect duplicate deliveries.
Transport Address: A transport address is typically defined by a
network-layer address, a transport-layer protocol, and a
transport-layer port number. In the case of SCTP running over IP,
a transport address is defined by the combination of an IP address
and an SCTP port number (where SCTP is the transport protocol).
Unordered Message: Unordered messages are "unordered" with respect
to any other message; this includes both other unordered messages
as well as other ordered messages. An unordered message might be
delivered prior to or later than ordered messages sent on the same
stream.
User Message: The unit of data delivery across the interface between
SCTP and its user.
Verification Tag: A 32-bit unsigned integer that is randomly
generated. The Verification Tag provides a key that allows a
receiver to verify that the SCTP packet belongs to the current
association and is not an old or stale packet from a previous
association.
1.4. Abbreviations
MAC Message Authentication Code [RFC2104]
RTO Retransmission Timeout
RTT Round-Trip Time
RTTVAR Round-Trip Time Variation
SCTP Stream Control Transmission Protocol
SRTT Smoothed RTT
TCB Transmission Control Block
TLV Type-Length-Value coding format
TSN Transmission Sequence Number
ULP Upper-Layer Protocol
1.5. Functional View of SCTP
The SCTP transport service can be decomposed into a number of
functions. These are depicted in Figure 2 and explained in the
remainder of this section.
SCTP User Application
-----------------------------------------------------
_____________ ____________________
| | | Sequenced Delivery |
| Association | | within Streams |
| | |____________________|
| Startup |
| | ____________________________
| and | | User Data Fragmentation |
| | |____________________________|
| Takedown |
| | ____________________________
| | | Acknowledgement |
| | | and |
| | | Congestion Avoidance |
| | |____________________________|
| |
| | ____________________________
| | | Chunk Bundling |
| | |____________________________|
| |
| | ________________________________
| | | Packet Validation |
| | |________________________________|
| |
| | ________________________________
| | | Path Management |
|_____________| |________________________________|
Figure 2: Functional View of the SCTP Transport Service
1.5.1. Association Startup and Takedown
An association is initiated by a request from the SCTP user (see the
description of the ASSOCIATE (or SEND) primitive in Section 11).
A cookie mechanism, similar to one described by Karn and Simpson in
[RFC2522], is employed during the initialization to provide
protection against synchronization attacks. The cookie mechanism
uses a four-way handshake, the last two legs of which are allowed to
carry user data for fast setup. The startup sequence is described in
Section 5 of this document.
SCTP provides for graceful close (i.e., shutdown) of an active
association on request from the SCTP user. See the description of
the SHUTDOWN primitive in Section 11. SCTP also allows ungraceful
close (i.e., abort), either on request from the user (ABORT
primitive) or as a result of an error condition detected within the
SCTP layer. Section 9 describes both the graceful and the ungraceful
close procedures.
SCTP does not support a half-open state (like TCP) wherein one side
continues sending data while the other end is closed. When either
endpoint performs a shutdown, the association on each peer will stop
accepting new data from its user and only deliver data in queue at
the time of the graceful close (see Section 9).
1.5.2. Sequenced Delivery within Streams
The term > rule encodes a comma
separated list of the particular component values present in the
SEQUENCE value, where each component value is preceded by the
corresponding identifier from the SEQUENCE type definition. The
components are encoded in the order of their definition in the
SEQUENCE type.
SequenceValue = ComponentList
ComponentList = "{" [ sp NamedValue *( "," sp NamedValue) ] sp "}"
NamedValue = identifier msp Value
msp = 1*%x20 ; one or more space characters
A value of a SET type is encoded according to the <SetValue> rule.
The components are encoded in the order of their definition in the
SET type (i.e., just like a SEQUENCE value). This is a deliberate
departure from ASN.1 value notation where the components of a SET can
be written in any order.
SetValue = ComponentList
SEQUENCE and SET type definitions are sometimes extended by the
inclusion of additional component types, so an implementation SHOULD
be capable of skipping over any <NamedValue> encoding with an
identifier that is not recognised, on the assumption that the sender
is using a more recent definition of the SEQUENCE or SET type.
3.14. SEQUENCE OF and SET OF
A value of a SEQUENCE OF type is encoded according to the
<SequenceOfValue> rule, as a comma separated list of the instances in
the value. Each instance is encoded according to the component type
of the SEQUENCE OF type.
SequenceOfValue = "{" [ sp Value *( "," sp Value) ] sp "}"
A value of a SET OF type is encoded according to the <SetOfValue>
rule, as a list of the instances in the value. Each instance is
encoded according to the component type of the SET OF type.
SetOfValue = "{" [ sp Value *( "," sp Value) ] sp "}"
Legg Standards Track [Page 10]
RFC 3641 Generic String Encoding Rules October 2003
3.15. CHARACTER STRING
A value of the unrestricted CHARACTER STRING type is encoded
according to the corresponding SEQUENCE type defined in Clause 40.5
of X.680 [8] (see [15] for equivalent ABNF).
CharacterStringValue = SequenceValue
3.16. EMBEDDED PDV
A value of the EMBEDDED PDV type is encoded according to the
corresponding SEQUENCE type defined in Clause 33.5 of X.680 [8] (see
[15] for equivalent ABNF).
EmbeddedPDVValue = SequenceValue
3.17. EXTERNAL
A value of the EXTERNAL type is encoded according to the
corresponding SEQUENCE type defined in Clause 8.18.1 of X.690 [12]
(see [15] for equivalent ABNF).
ExternalValue = SequenceValue
3.18. INSTANCE OF
A value of the INSTANCE OF type is encoded according to the
corresponding SEQUENCE type defined in Annex C of X.681 [9].
InstanceOfValue = SequenceValue
3.19. REAL
A value of the REAL type MUST be encoded as "0" if it is zero,
otherwise it is encoded as the special value <PLUS-INFINITY>, the
special value <MINUS-INFINITY>, an optionally signed <realnumber>, or
as a value of the corresponding SEQUENCE type for REAL defined in
Clause 20.5 of X.680 [8] (see [15] for equivalent ABNF).
RealValue = "0" ; zero REAL value
/ PLUS-INFINITY ; positive infinity
/ MINUS-INFINITY ; negative infinity
/ realnumber ; positive base 10 REAL value
/ "-" realnumber ; negative base 10 REAL value
/ SequenceValue ; non-zero REAL value, base 2 or 10
Legg Standards Track [Page 11]
RFC 3641 Generic String Encoding Rules October 2003
realnumber = mantissa exponent
mantissa = (positive-number [ "." *decimal-digit ])
/ ( "0." *("0") positive-number )
exponent = "E" ( "0" / ([ "-" ] positive-number))
PLUS-INFINITY = %x50.4C.55.53.2D.49.4E.46.49.4E.49.54.59
; "PLUS-INFINITY"
MINUS-INFINITY = %x4D.49.4E.55.53.2D.49.4E.46.49.4E.49.54.59
; "MINUS-INFINITY"
3.20. Variant Encodings
The values of some named complex ASN.1 types have special string
encodings. These special encodings are always used instead of the
encoding that would otherwise apply based on the ASN.1 type
definition.
VariantEncoding = RDNSequenceValue /
RelativeDistinguishedNameValue /
ORAddressValue
A value of the RDNSequence type, i.e., a distinguished name, is
encoded according to the <RDNSequenceValue> rule, as a quoted LDAPDN
character string. The character string is first derived according to
the <distinguishedName> rule in Section 3 of RFC 2253 [5], and then
encoded as if it were a UTF8String value, i.e., between double quotes
with any embedded double quotes escaped by being repeated.
RDNSequenceValue = StringValue
A RelativeDistinguishedName value that is not part of an RDNSequence
value is encoded according to the <RelativeDistinguishedNameValue>
rule as a quoted character string. The character string is first
derived according to the <name-component> rule in Section 3 of RFC
2253 [5], and then encoded as if it were a UTF8String value.
RelativeDistinguishedNameValue = StringValue
A value of the ORAddress type is encoded according to the
<ORAddressValue> rule as a quoted character string. The character
string is first derived according to the textual representation of
MTS.ORAddress from RFC 2156 [2], and then encoded as if it were an
IA5String value.
ORAddressValue = StringValue
Legg Standards Track [Page 12]
RFC 3641 Generic String Encoding Rules October 2003
4. GSER Transfer Syntax
The following OBJECT IDENTIFIER has been assigned by Adacel
Technologies, under an arc assigned to Adacel by Standards Australia,
to identify the Generic String Encoding Rules:
{ 1 2 36 79672281 0 0 }
This OBJECT IDENTIFIER would be used, for example, to describe the
transfer syntax for a GSER encoded data-value in an EMBEDDED PDV
value.
5. Security Considerations
The Generic String Encoding Rules do not define a canonical encoding.
That is, a transformation from a GSER encoding into some other
encoding (e.g., BER) and back into GSER will not necessarily
reproduce the original GSER octet encoding. Therefore, GSER MUST NOT
be used where a canonical encoding is needed.
Furthermore, GSER does not necessarily enable the exact octet
encoding of values of the TeletexString, VideotexString,
GraphicString or GeneralString types to be reconstructed, so a
transformation from a Distinguished Encoding Rules (DER) [12]
encoding to GSER and back to DER may not reproduce the original DER
encoding. Therefore, GSER MUST NOT be used to re-encode, whether for
storage or transmission, ASN.1 abstract values whose original binary
encoding must be recoverable. Such recovery is needed for the
verification of digital signatures. In such cases, protocols ought
to use DER or a DER-reversible encoding.
When interpreting security-sensitive fields, and in particular fields
used to grant or deny access, implementations MUST ensure that any
comparisons are done on the underlying abstract value, regardless of
the particular encoding used.
6. References
6.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
Legg Standards Track [Page 13]
RFC 3641 Generic String Encoding Rules October 2003
[4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997.
[5] Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access
Protocol (v3): UTF-8 String Representation of Distinguished
Names", RFC 2253, December 1997.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[7] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
Information Technology - Open Systems Interconnection - The
Directory: Selected attribute types
[8] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002
Information technology - Abstract Syntax Notation One (ASN.1):
Specification of basic notation
[9] ITU-T Recommendation X.681 (07/02) | ISO/IEC 8824-2:2002
Information technology - Abstract Syntax Notation One (ASN.1):
Information object specification
[10] ITU-T Recommendation X.682 (07/02) | ISO/IEC 8824-3:2002
Information technology - Abstract Syntax Notation One (ASN.1):
Constraint specification
[11] ITU-T Recommendation X.683 (07/02) | ISO/IEC 8824-4:2002
Information technology - Abstract Syntax Notation One (ASN.1):
Parameterization of ASN.1 specifications
[12] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002
Information technology - ASN.1 encoding rules: Specification of
Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)
6.2. Informative References
[13] Hovey, R. and S. Bradner, "The Organizations Involved in the
IETF Standards Process", BCP 11, RFC 2028, October 1996.
[14] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol
(v3): Technical Specification", RFC 3377, September 2002.
[15] Legg, S., "Common Elements of Generic String Encoding Rules
(GSER) Encodings", RFC 3642, October 2003.
Legg Standards Track [Page 14]
RFC 3641 Generic String Encoding Rules October 2003
[16] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
Information Technology - Open Systems Interconnection - The
Directory: Overview of concepts, models and services
7. Intellectual Property Notice
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
8. Author's Address
Steven Legg
Adacel Technologies Ltd.
250 Bay Street
Brighton, Victoria 3186
AUSTRALIA
Phone: +61 3 8530 7710
Fax: +61 3 8530 7888
EMail: steven.legg@adacel.com.au
Legg Standards Track [Page 15]
RFC 3641 Generic String Encoding Rules October 2003
9. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Legg Standards Track [Page 16]