| Network Working Group | C.M. Lonvick |
| Internet-Draft | May 22, 2011 |
| Intended status: Informational | |
| Expires: November 23, 2011 |
A Taxonomy on Private Use Fields in Protocols
draft-lonvick-private-tax-01.txt
The fields in protocols that are reserved for private use have been purposefully unregulated. This document attempts to provide some classifications for the way that private use fields have been used in protocols developed in the IETF.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 23, 2011.
Copyright (c) 2011 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Simply put, communications protocols are standardized ways for computing entities to convey information. Within each communications protocol, there must be standardized pieces of information that will be communicated, and there may be non-standardized information that can be communicated.
Time Protocol [RFC0868] is an example of a protocol that only conveys standardized information. There is no way to add anything other than what is specified in the document. On the other hand, DoD standard Transmission Control Protocol [RFC0761] does have "options" but they must be registered through the IANA [IANAtcp], which does not leave any room for optional information supplied by equipment vendors, network operators, or experimenters. Finally, Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4) [RFC3925] does allow for vendor specific options.
If a network operator wanted to add specific information to the Time Protocol [RFC0868], they could modify the code of the senders and receivers and run this within their own domain without any problems. However, if an equipment vendor wanted to include information specific to their equipment, they would have to ensure that all senders and receivers within all network domains would either accept the change in the protocol, or would not have problems with it. As a final case, if several equipment vendors desired to add equipment-specific information to this protocol, they would have to take great care that only their own receivers would accept information from their own transmitters. An extension to that would be that if one equipment vendor would like to transmit or receive the same information that another vendor is using.
For the case of TCP [RFC0761], standard options are expected; senders may use them and receivers may be configured to act upon that information, or to ignore it. If an experimenter wants to add an option, they will have to create a new IETF RFC with the details, or obtain approval from the IESG to have the IANA add to the registry [IANAtcp]. Similarly, if equipment vendors Foo and Bar were to have a need for a similar option within TCP, they would each have to go through the process to add to the registry. On the other hand, if a properly crafted multipurpose, private use option were to be registered, such as in the case of multiple vendor instances within Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4) [RFC3925] then vendors and experimenters would each be able to use it for their own purposes as long as all network participants can easily differentiate between the entities using the option.
This document explores the various ways that protocols may allow optional information using fields designated as "private use" to be included in protocols, without disrupting the desired harmony of the network. [RFC4735]
Guidelines for Writing an IANA Considerations Section in RFCs [RFC2432] describes that values of specific name spaces may either be registered with the IANA, or not. In most cases, there are well defined values for name spaces. However, as the document explains, not all name spaces require centralized administration.
In that document, it seems to be assumed that private use name spaces will be domain specific and it will be up to the administrators of any domain to avoid conflicts. The first example given about private use name spaces refers to Dynamic Host Configuration Protocol [RFC2131] and presumably DHCP Options and BOOTP Vendor Extensions [RFC2132]. In this the example states that "site-specific options in DHCP have significance only within a single site". As noted below this became a problem that was rectified in a later revision of DHCP.
Later works identified a need to place a scope on private use name spaces. The second example of private use name spaces in [RFC2432] is from STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES [RFC0822] which describes X- headers. Again, there is no effort made to control the name space. It appears however that the users of X- headers have self-organized; most consistently use features that are universally useful and many have incorporated identifiers for useful features that may overlap.
In this document, the following words are defined to prevent ambiguity. Some of these words have not been used in the referenced works but their meanings can be ascertained.
[timeQuality tzKnown="0" isSynced="0"]
<165>1 2003-10-11T22:14:15.003Z mymachine.example.com
evntslog - ID47 [exampleSDID@32473 iut="3" eventSource=
"Application" eventID="1011"] BOMAn application
event log entry...
Examples
This section contains a review of RFCs that allow the use of private use options. There seem to be three ways to address the name space: via a global origin, via a truncated numerical origin, and via a namespace based upon the domain name.
Likely, the first private use option was defined in the Structure and Identification of Management Information for TCP/IP-based Internets [RFC1155] which was first used in A Simple Network Management Protocol [RFC1067] (SNMP). The structure of management information (SMI) has been updated and is currently defined as the Structure of Management Information Version 2 (SMIv2) [RFC2578].
SMI is a well described tree of OBJECT IDENTIFIERs. It has an origin and a path for defined object identifiers which this document describes as standard options. It also allows for experimental and vendor specific object identifiers, which are described as private use options in this document. The IANA maintains a registry of these Network Management Parameters [IANAsmi].
The Internet subtree of experimental OBJECT IDENTIFIERs starts with the prefix: 1.3.6.1.3., and the Internet subtree of private enterprise OBJECT IDENTIFIERs starts with the prefix: 1.3.6.1.4.1. This is followed by a Private Enterprise Number [IANApen] (PEN) and then the OBJECT IDENTIFIERs defined by that enterprise.
While this is very practical and practicable for SNMP, fully qualified SMIs do not lend themselves well for other uses as a generic private use option.
Rather than using the entire SMI, protocol engineers started using just the Private Enterprise Number [IANApen]. This reduces the length of the identifier but continues to provide an identifier through a globally unique name space. This subsection provides examples of how the PEN has been used to provide private use options.
The Remote Authentication Dial In User Service (RADIUS) [RFC2058] specification documented how to use just the PEN (without the rest of the SMI path to the root) to allow "vendors" to articulate their own options. In that document, these are called Vendor-Specific Attributes (VSA).
The updated RADIUS document, [RFC2865], gives guidance for using the VSA.
There are many attributes defined in RADIUS [RFC2058] which may be considered to be standard variables. Each of these attributes are specified within a "type length value" (tlv) container. For this protocol, the VSA "type" is a specific numerical value which separates it from other attributes. Type 26 (decimal) denotes a VSA, and the PEN starts the "value" which should then include a subsequent nested tlv so the vendor may enumerate their own options within the field.
Mobile IP Vendor Specific Extensions [RFC3115] defines two extensions that can be used for making organization specific extensions by vendors/organizations for their own specific purposes for Mobile IP [RFC2002]. Mobile IP has been revised several times and is currently specified in IP Mobility Support for IPv4, Revised [RFC5944].
In that specification, two tlv's have been defined to contain private use options. These are called Vendor/Organization Specific Extensions (VSE). [RFC2002] which states:
Having two VSEs of this nature for private use options is consistent with the original Mobile IP specification
The introduction to Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4) [RFC3925] states:
This meant that Dynamic Host Configuration Protocol [RFC2131] specified that there was one instance of the vendor type, and the receiver used that name space to set the scope for the fields in the vendor-specific information option.
This situation was resolved with the publication of Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4) [RFC3925] which states:
That specification ([RFC3925]) then used the PEN [IANApen] to define a unique name space for private use options in this protocol. Similar to other protocols of this era, tlv containers were used.
The Syslog Protocol [RFC5424] also uses the PEN to uniquely qualify the name space for a private use option. Standard options do not contain the "@" character. Private use options must have the PEN following the "@" character. This allows a vendor or experimenter to have overlapping name spaces which the PEN will then uniquely identify. For example a standard option is tzKnown which may only have associated values of "0" and "1". However tzKnown@32473 may have any value assigned to it by the owner of enterprise number 32473.
Syslog transport receivers are supposed to accept all correctly formatted Syslog messages. Unlike RADIUS, the receiving Syslog application does not have to have immediate knowledge of all variable options to continue operations. If a private use option is not immediately known to the receiving application, it may still store the message and an Operator or Administrator may look it up at a later time if they are really interested.
The Secure Shell (SSH) Protocol Architecture [RFC4251] uses character strings rather than PENs. Similar to Syslog, but actually predating it, standard options must not have the "@" character in them. Private use options will have an origin identifier preceding an "@" character followed by a name space field. For example, in The Secure Shell (SSH) Connection Protocol [RFC4254] SSH channels may be opened by specifying a channel type when sending the SSH_MSG_CHANNEL_OPEN message. Standard options for the channel type include "session" and "x11". A private use option for a channel type could be "example_session@example.com".
Obviously, these character strings are domain names [RFC1034] [RFC1035]. This is specified in The Secure Shell (SSH) Protocol Architecture [RFC4251]. Generally, the guidance given is that if a private use option of this nature is not understood it is to convey an error code to its peer.
This section summarizes the observed characteristics of private use options that are successful and deployed.
There seem to be three characteristics of successful private use options.
A private use option requires a path to an origin that has the authority to create and maintain the option. As shown above, this referent should be unique, and not be dependent upon local interpretation.
The PEN [pen] is sourced by the Internet Assigned Numbers Authority (IANA). While there seems to be no reports of problems using PENs, PENs do not seem to be unique. It appears that some private enterprises have registered multiple PENs, and that there are some private enterprises whose PENs are no longer serviceable, mostly because they have been acquired by other companies, or they have gone out of business.
Domain names have similar problems as they can be more ephemeral than eternal. The top level domains are maintained by the Internet Corporation for Assigned Names and Numbers [ICANN] however the specific names are assigned much more locally. Unlike PENs that become unserviceable when their owning organization goes out of business, domain names that fall into disuse may be acquired and used by entirely different organizations. Again however, like the use of PENs there have not been any problems reported from this.
Once the source of authority is established, an actual option, or multiple options, must be specified. This is usually an indicator of what value is expected. Within the domain established by the source of authority, the focus of each value must be unique. In a very simple example, a private use option may consist of "PEN"@"focus"="value". The PEN will be unique and will specify the source of authority. The focus will be unique as long as the source of authority maintains that uniqueness; e.g., it would be poor form for a private enterprise to define a focus, then to redefine it at a later time.
In some cases, multiple focuses and values need to be transmitted. When the PEN has been used, this has most often been achieved by nesting tlv's within the field. Each type is then a focus for the private use option.
Within the protocol, an understanding needs to be established between the transmitter and receiver about what to do if the receiver does not understand a focus. Some protocols have defined that a receiver will silently discard packets that contain private use options they do not understand. Other protocols have defined that they will only discard the private use option rather than the entire packet. While other protocols have no need for the receiver to have any understanding of any private use options. If this understanding is not established in the protocol then some means needs to be enabled so that the endpoints of the protocol can discuss this and form a resolution to one of them not understanding a private use option.
The value of each private use option must be extensible but bounded.
Generally speaking, values of private use options should follow the same guidance given for standard options.
The globally unique origin in SNMP [smi] is the International Standards Organization [ISO] which is accredited by the United Nations to maintain this structure. However, the namespace resolves to the PEN [pen] which does not seem to be globally unique.
After the vendor identifier (the PEN) in the management information base (MIB), a vendor can create many different trees to identify objects. This may result in a very large number of OBJECT IDENTIFIERs; each of which is an identifier of the name space described in this document. Each of these are uniquely identified by the vendor and do not require registration with any coordinating authority.
The last item in each OBJECT IDENTIFIER is the value corresponding to the focus. In a GetRequest the server fills this field with a "0" and the client responds by replacing the "0" with the actual value. In a SetRequest transmitted to the receiver, this is the last field.
In this, each OBJECT IDENTIFIER contains a globally unique origin which is ISO, a focus which is the OBJECT IDENTIFIER down to the last field, and a value which is the last field in the SetRequest, and the last field in the response to a GetRequest.
As noted above, the globally unique origin for RADIUS [RFC2865] is the PEN.
The remainder of the Attribute field after the PEN is deliberately undefined in the specification. It is however suggested that the field contain embedded tlv's. This is again very practical and practicable. Each vendor may then have conflicting "types" (e.g. "1") which would be disambiguated by the origin. For example {PEN="N", type="1"} is different from {PEN="M", type="1"}. Since there is nothing to prevent vendors from registering multiple PENs, each vendor may have a plethora of {type="1"}. However, that is actually not needed since the focus may be extended by enumerating multiple types. For example, the vendor attribute may contain {PEN="M", type="1"(value), type="2"(value), type="3"(value)}.
The values for each type are bounded by the length of the attribute. Since the entire vendor attribute is defined by the vendor, the values may be human readable or binary. Since the protocol tends to be machine-to-machine, it is likely that the values will be binary. It is feasible that the value have no length. In that case, the transmission of the type alone, would be a signal of some sort to the receiver.
The structure of the origin, type, and value of the CVSEs and NVSEs for Mobile IP [RFC3115] may be used in a manner very similar to that of RADIUS. The PEN is the origin and types and values may be stacked within the field following that.
It should be noted that this does not have to be the case. Specifying CVSEs and NVSEs in various packets can give a vendor another dimension in processing these private use fields. If a vendor placed all CVSEs in a single packet, and the receiver did not understand any one of them, the entire packet must be discarded. However, if the vendor places individual CVSEs in separate packets, only CVSEs that are not understood by the receiver will be discarded.
Similarly, a vendor may choose to not stack NVSEs so that a receiver won't discard the entire cluster of NVSEs if a single one is not understood.
The values are constrained by the length of the types or subtypes.
It is not known by the author if this separation of CVSEs into multiple packets, or if the separation of NVSEs by a single vendor is currently practiced. Any clue from the clueful would be appreciated here.
The first version of the DHCP protocol [RFC2131] did not allow for multiple origins; only a single origin was permitted and the types were to be defined subsequent to that. The author of this document does not know the history of this specification but it seems to be that this was unworkable so the specification was changed to allow for multiple origins. After that, it becomes very similar to CVSEs and NVSEs described in Mobile IP [RFC3115], however multiple uses of the PEN are not permitted.
The Syslog protocol [RFC5424] uses the PEN as the origin and allows for the focus of the private use option to be fully defined by the vendor within the structured data. Specifically, a vendor may define a "type" of private use option by concatenating it with the PEN by using the @ character. Within the bounds of the structured data, multiple elements may be used that have identifiers and values.
Finally, in the SSH protocol [RFC4250], the origin is a domain name and the focus of the option is dependent upon context. For example, ourcipher-cbc@example.com can only be used when negotiating ciphers, while example_session@example.com can only be used when negotiating channel types, per the examples in [RFC4250].
Private use options are useful to the community and are gaining popularity. This is a way to allow vendors, network operators, and experimenters to convey dynamic information without going through a rigorous process to register each variable.
There is no "one size fits all" mechanism. The use of a very specific and fixed format works very well for RADIUS which requires speed in processing. On the other hand, the open nature of the private use options in Syslog is appropriate for that protocol.
The structure of the SMI is uniform and globally unique, but the pen is not up to date. It appears that the people listed as the contacts for some of the organizations have moved on, and that some of the organizations have either been acquired by other organizations or have gone out of business. It also appears that some organizations have registered multiple PENs. The author is really not sure why they would need to do that so any clue here would be appreciated.
Using the PEN with an extension or even with an entire SMI may be constrained to fit nicely into a binary oriented protocol that has strict field lengths. Using domain names, as SSH does, may also be fit within binary protocols but since domain name lengths vary, tlv's or some other mechanism may need to be used to establish the boundaries of fields.
RADIUS dictates what to do if a private use option is not understood by a receiver. Mobile IP Vendor Specific Extensions [RFC3115] builds on that by letting a receiver know if it must process the entire packet containing a private use option, or if it may ignore a private use option that it doesn't understand but yet continue processing the rest of the packet. On the other hand, Syslog does not require a receiver to understand anything about any private use options. It is expected that receivers that do understand the private use options will be able to take actions more appropriately based on the information they receiver.
From that, it is important to define in protocol specifications what actions to take when a receiver receives a frame with a private use options.
This section will be removed prior to publication.
This is version -01. I revised the section on source/focus/value to give an overview and then examples. I also removed the section on IPFIX. It wasn't adding anything new and was a bit difficult to write.
I still need to revise the Issues section. I'd like to write a lot more description there but I want this version out the door first.
This document reviews ways that options are being used in various protocols. As such, there are no security considerations inherent in this document.
Readers and implementers should be aware of the context of implementing options in their own protocols.
This document does not propose a standard and does not require the IANA to do anything.
The idea for documenting this came from questions asked in the SIP-CLF Working Group and the author is grateful for the discussion around this topic.
The following people have contributed to this document. Listing their names here does not mean that they endorse the document, but that they have contributed to its substance.
David Harrington, Dan Romascanu and Bert Wijnen.