Internet Engineering Task Force Erik Guttman
INTERNET DRAFT Sun Microsystems
Standards Track: Updates RFC 2608
25 September 2001
ExpiresA new Request for Comments is now available in six months online RFC libraries.
RFC 3224
Title: Vendor Extensions for Service Location Protocol,
Version 2
draft-guttman-svrloc-vendor-ext-06.txt
Status of this Memo
This document is an individual contribution for consideration by
the Internet Engineering Task Force. Comments should be submitted
to the svrloc@svrloc.org mailing list.
Author(s): E. Guttman
Status: Standards Track
Date: January 2002
Mailbox: erik.guttman@sun.com
Pages: 10
Characters: 19618
Updates: 2608
I-D Tag: draft-guttman-svrloc-vendor-ext-07.txt
URL: ftp://ftp.rfc-editor.org/in-notes/rfc3224.txt
This document is intended
to be submitted to specifies how the IESG for consideration as an Informational
RFC.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents features of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Copyright (C) The Internet Society 2001. All Rights Reserved.
Abstract
The Service Location
Protocol, Version 2 [1] allows allow for vendor
extensibility. This document updates the standard, specifying
how each of these features can be used safely (with extensibility safely, with
no possibility of name collisions). collisions. The specification introduces a new
SLPv2 extension: The Vendor Opaque Extension. While proprietary
protocol extensions are not encouraged by IETF standards, it is
important that when they
are undertaken they not hinder interoperability of compliant
implementations.
implementations when they are undertaken. This document also defines a new extension to
SLPv2: The Vendor Opaque extension.
Table of Contents
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . 3
2.0 Enterprise Numbers . . . . . . . . . . . . . . . . . . 3
3.0 Naming Authorities . . . . . . . . . . . . . . . . . . 3
4.0 Vendor Defined Attributes . . . . . . . . . . . . . . 4
5.0 Vendor Opaque Extension . . . . . . . . . . . . . . . 5
5.1 Vendor Opaque Extension Format . . . . . . . . . . 6
5.2 Example: Acme Extension for UA Authentication . . 6
6.0 Extensions Requiring IETF Action . . . . . . . . . . . 7
7.0 IANA Considerations . . . . . . . . . . . . . . . . . 7
8.0 Security Considerations . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
References . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . 9
1.0 Introduction
The udpates RFC
2608, "The Service Location Protocol, Version 2 [1] defines a number of
features which are extensible. Protocol."
This document clarifies exactly which
mechanisms can be used to that end (Sections 3-5) and which cannot
(Section 6). is now a Proposed Standard Protocol.
This document specifies conventions that ensure the
protocol extension mechanisms in the SLPv2 specification will not
possibly have ambiguous interpretations.
This specification introduces only one new an Internet standards track protocol element, the
Vendor Opaque Extension. This Extension makes it possible for a
vendor to extend SLP independently, once
the vendor has registered
itself with IANA Internet community, and obtained an Enterprise Number. This is useful requests discussion and suggestions
for vendor-specific applications.
Vendor extensions improvements. Please refer to standard protocols come at a cost.
- Vendor extensions occur without review from the community. They
may not make good engineering sense in the context current edition of the
protocol they extend, and the engineers responsible may discover
this too late.
- Vendor extensions preclude interoperation with compliant but
non-extended implementations. There is a real danger of
incompatibility if different implementations support different
feature sets.
- By extending SLPv2 privately, ubiquitous automatic configuration
is impossible, which is
"Internet Official Protocol Standards" (STD 1) for the primary benefit
standardization state and status of a standard
service discovery framework.
For these reasons, registration this protocol. Distribution
of service templates with IANA this memo is
strongly encouraged! unlimited.
This process announcement is easy and has proved sent to be rapid
(taking less than 2 weeks in most cases).
1.1 Terminology
In this document, the key words "MAY", "MUST", "MUST NOT",
"optional", "recommended", "SHOULD", IETF list and "SHOULD NOT", are the RFC-DIST list.
Requests to be
interpreted as described in [2].
Service Location Protocol terminology is defined in [1]. IANA
registration terminology is defined in [5].
2.0 Enterprise Number
Enterprise Numbers are used to distinguish different vendors in IETF
protocols. Vendor Extensions to SLPv2 SHOULD use these values to
avoid any possibility of a name space collision. Each vendor is
responsible for ensuring that vendor extensions under their own
authority are non-conflicting.
RFC 1700 lists the Enterprise Numbers registered at the time of
publication as well as rules on how added to register new numbers:
To request an assignment of an Enterprise Number send the
complete company name, address, and phone number; and or deleted from the
contact's person complete name, address, phone number, and
email mailbox in an email message to <iana-mib@isi.edu>. [3]
The complete up-to-date IETF distribution list is maintained by IANA [3].
3.0 Naming Authorities
Naming Authorities are defined by SLPv2 [1] as an agency or group
which catalogues Service Types and attributes.
A Service Type is a string representing a service which can be
discovered by SLPv2. Attributes may be associated with a particular
Service Type which is advertised by SLPv2.
Service Type strings and service attributes may
should be registered with
IANA by creating a Service Template [4]. The template is included in
an internet draft and an email message is sent to srvloc-
list@iana.org requesting that the template be included in the Service
Template registry. In this case the naming authority for the service
type is IANA.
It is also possible for a Vendor IETF-REQUEST@IETF.ORG. Requests to create their own naming
authority. In this case, any service type or attributes may be used.
SLPv2 allows arbitrary naming authorities
added to coexist. To use an
explicit naming authority, a vendor simply employs their Enterprise
Number as a naming authority. For example, for the following
(fictitious) Enterprise Number
9999 Acme, Inc. Erik Guttman femur@example.com or deleted from the Naming Authority string to use would RFC-DIST distribution list should
be "9999". A service: URL
which used this Naming Authority sent to advertise a Roadrunner Detector
service could look like
service:roadrunner-detector.9999://example.com:9341
Service types which are defined under a naming authority based RFC-DIST-REQUEST@RFC-EDITOR.ORG.
Details on an
Enterprise Number are guaranteed not to conflict with other service
type strings which mean something entirely different. That is also
true of attributes defined for service types defined under a naming
authority.
To create a safe naming authority with no possibility of name
collisions, a vendor SHOULD use their Enterprise Number as a naming
authority.
4.0 Vendor Defined Attributes
SLPv2 [1] suggests that
Non-standard attribute names SHOULD begin with "x-",
because no standard attribute name will ever have those
initial characters.
It is possible that two non-standard attributes will conflict that
both use the "x-" prefix notation. For that reason, vendors SHOULD
use "x-" followed by their Enterprise Number followed obtaining RFCs via FTP or EMAIL may be obtained by a "-" to
guarantee that the non-standard attribute name's interpretation is
not ambiguous.
For example, Acme, Inc.'s Enterprise Number is 9999. Say the
Service Template for NetHive (a fictitious game) was:
------------------------------------------------------------
template-type=NetHive
template-version=1.0
template-description=
The popular NetHive game.
template-url-syntax=
url-path = ; There is no path for a NetHive service URL.
features= string M O
# The list of optional features the NetHive server supports.
secure session, fast mode
current-users= string M
# The list of users currently playing
------------------------------------------------------------
Acme's server advertises a feature which is not on the list
of standard features, "x-9999-cheat-mode". Only sending
an Acme
client would request this attribute to discover servers,
since it is not standard.
5.0 Vendor Opaque Extension
SLPv2 [1] defines a protocol extensibility mechanism. SLPv2
Extensions are added at the end of a EMAIL message and have the
following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension ID | Next Extension Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset, contd.| Extension Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Extension Data depends on the Extension ID. Refer to [5] for a full description of different mechanisms available for
registration of values rfc-info@RFC-EDITOR.ORG with IANA.
SLPv2 may be extended in any of three ways.
(1) Anyone may request the designated expert for SLP to register a
new extension ID with IANA. Send requests to the svrloc-
list@iana.org.
It is recommended that an internet draft specifying this
extension be published, with the intention of publishing the
document as an Informational RFC. This way others can use the
extension as well. This is not a 'vendor extension' - rather
this is the preferred way of extending the protocol in a vendor
neutral manner.
If no specification is published and the extension is intended
for vendor specific use only - the 'Vendor Extension' option
below probably makes more sense than assigning an extension ID.
(2) An experimental extension may be done using the range 0x8000 to
0x8FFF. There is always the risk, however, that another vendor
will use the same ID, since these IDs are not registered.
(3) A Vendor Extension may be used. This extension allows a Vendor
to define their own extensions which are guaranteed to have a
unique interpretation. It is OPTIONAL to implement.
5.1. Vendor Opaque Extension Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension ID = 0x0003 | Next Extension Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset, contd.| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ent. #, contd.| Extension Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Enterprise Number is included in the Extension as a 4 byte
unsigned integer value. The Extension Data following is guaranteed
to have an unambiguous interpretation determined by the vendor.
5.2 Example: Acme Extension message body
help: ways_to_get_rfcs. For example:
To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for UA Authentication
The Acme Corporation, whose Enterprise Number is 9999, can define an
extension to SLP. In this example, Acme creates one such extension
to create an application level access control to service information.
This would allow replies to special distribution should be sent only to clients who could
authenticate themselves.
The engineers at Acme give the Extension Data the following form:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ACME Ext ID = 1| Client ID Length | Client ID ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ACME Ext ID: The ACME engineers decided addressed to define either the first byte
author of
their extension data as an extension ID field. In the future, ACME
may decide to define more than this extension. Since there is 8 bits RFC in the ID field, ACME can define up to 256 different extensions. If
ACME were to omit this field and begin directly with their 'Extension
for UA Authentication', they would only be able to define one ACME
specific SLP extension. For the 'Extension for UA Authentication,'
the ACME Extension ID is set to 1. This ID has to be managed within
ACME, to make sure that each new extension they invent has a unique
ID assigned question, or to it.
Client ID Length: This declares how many bytes of Client ID data
follows.
Client ID: The Acme application user ID.
Timestamp: # of seconds since January 1, 2000, 0:00 GMT.
Authenticator: a 16 byte MD5 digest [6] calculated RFC-Manager@RFC-EDITOR.ORG. Unless
specifically noted otherwise on the following
data fields, concatenated together
- UA request bytes, including the header, but not any extensions.
- UA SECRET PASS PHRASE
- Acme UA Authentication Extension - Client ID
- Acme UA Authentication Extension - Timestamp
The SA or DA which receives this extension and supports this
extension will check if it (1) recognizes the Client ID, (2) has an
associated SECRET PASS PHRASE for it, (3) whether upon calculating an
MD5 digest over the same data as listed above it arrives at the same
Authenticator value as included in the extension. If RFC itself, all 3 of these
steps succeed, the UA has been authenticated.
Note this example is for explanatory purposes only. It would not
work well in practice. It requires a shared secret be configured in
SAs and DAs, RFCs are for every UA. Furthermore, the UA secret pass phrase
would be susceptible to a dictionary attack.
6.0 Extensions Requiring IETF Action
Terminology and procedures
unlimited distribution.echo
Submissions for IETF Actions related to registration
of IDs with IANA are defined in [5]. Existing SLPv2 extension
assignments are registered with IANA [7].
7.0 IANA Considerations
This document clarifies procedures described in other documents [1]
[4]. The Vendor Opaque Extension ID has already been registered [7].
No additional IANA action is required Requests for publication of this
document.
8.0 Security Considerations
Vendor extensions may introduce additional security considerations
into SLP.
This memo describes mechanisms which are standardized elsewhere [1]
[4]. The only protocol mechanism described in this document (see
Section 5 above) is no less secure than 'private use' extensions
defined in SLPv2 [1].
The example in Section 5.2 above shows how Vendor Opaque Extensions
can Comments should be used to include an access control mechanism to SLP so that SAs
can enforce an access control policy using an authentication
mechanism. This is merely an example and protocol details were
intentionally not provided. A vendor could, however, create a
mechanism similar to this one and provide additional security
services to SLPv2 in the manner indicated in the example.
Acknowledgements
I thank the IESG, for their usual persistence and attention sent to
detail.
References
[1] Guttman, E., Perkins, C., Veizades, J., Day, M., "Service Location
Protocol, Version 2",
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2608, July 1999.
[2] Bradner, S., "Key words for use in RFCs 2223, Instructions to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] http://www.iana.org/numbers.html
[4] Guttman, E., Perkins, C., Kempf, J., "Service Templates and URLs",
RFC 2609, July 1999.
[5] Narten, T. and H. Alvestrand, "Guidelines
Authors, for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[7] ftp://www.iana.org/assignments/svrloc-extensions
Author's Address
Erik Guttman
Sun Microsystems
Eichhoelzelstr. 7
74915 Waibstadt
Germany
Phone: +49 7263 911 701
Messages: +49 6221 356 202
Email: erik.guttman@sun.com further information.