Internet Engineering Task Force Erik Guttman
INTERNET DRAFT Sun Microsystems
Category: Standards Track Obseletes: RFC 2608 November 7, 2001 Expires
in six months
Service Location Protocol, Version 2
<draft-guttman-svrloc-rfc2608bis-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Comments on this document should be sent to the
author and to the SLP discussion list, srvloc-
discuss@lists.sourceforge.net.
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 provides a scalable framework for the
discovery and selection of network services. Using this protocol,
computers using the Internet need little or no static configuration
of network services for network based applications. This is
especially important as computers become more portable, and users
less tolerant or able to fulfill the demands of network system
administration. This document updates SLPv2, adding clarifications
and removing features which were neither widely implemented or deemed
useful.
Acknowledgements
Authors of previous versions of this document (listed alphabetically)
contributed enormously to the development of SLPv2:
Mike Day, Scott Kaplan, Charles Perkins, John Veizades
Insightful comments from Mikael Pahmp initiated the process of
Guttman Expires: 7 May 2001 [Page 1]
Internet Draft SLPv2 Revision November 2001
revising SLPv2. Thanks to contributors this specification:
Kevin Arnold, Michael Day, Evan Hughes, James Kempf, Terry Lambert,
Ira McDonald, James Woodyatt, Weibin Zhao
1. Introduction
The Service Location Protocol (SLP) provides a flexible and scalable
framework for providing hosts with access to information about the
existence, location, and configuration of networked services.
Traditionally, users have had to find services by knowing the name of
a network host (a human readable text string) which is an alias for a
network address. SLP eliminates the need for a user to know the name
of a network host supporting a service. Rather, the user supplies
the desired type of service and a set of attributes which describe
the service. Based on that description, the Service Location
Protocol resolves the network address of the service for the user.
SLP provides a dynamic configuration mechanism for applications in
local area networks. Applications are modeled as clients that need
to find servers attached to any of the available networks within an
enterprise. For cases where there are many different clients and/or
services available, the protocol is adapted to make use of nearby
Directory Agents that offer a centralized repository for advertised
services.
This document obseletes SLPv2 [RFC2608], correcting protocol errors
and removing some requirements. A separate SLPv2 applicability
statement [SLPv2AS] describes both where the protocol's domain of
applicability lies as well as the interoperability aspects of this
specification with prior versions of the protocol.
2. Terminology and Conventions used in this Document
User Agent (UA)
A process working on the user's behalf to establish contact with
some service. The UA retrieves service information from the
Service Agents or Directory Agents.
Service Agent (SA)
A process working on the behalf of services to advertise them.
Directory Agent (DA)
A process which collects service advertisements. There can only
be one DA present per given host.
Service Type
Each type of service has a unique Service Type string. The
default service type for a 'generic' URI is its scheme name. For
example, the service type string for "http://www.srvloc.org" would
be "http".
Guttman Expires: 7 May 2001 [Page 2]
Internet Draft SLPv2 Revision November 2001
Naming Authority
The agency or group which catalogues given Service Types and
Attributes. The default Naming Authority is IANA.
Scope
A set of services, making up a logical administrative group.
Service URL
A Service URL indicates the location of a service. This URL may
be of the service: scheme [RFC2609] or any other scheme conforming
to the URI standard [RFC2396]. URIs without address
specifications SHOULD NOT be advertised by SLP.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
In packet diagrams, any field terminating with a '\' indicates a
variable length field, given by a prior length field in the protocol.
Protocol requirements are listed explicitely, by number, between
braces, to simplify interoperability testing.
3. Protocol Overview
SLP discovery support for client applications is supplied by 'User
Agents.' SLP service advertising support for services are provided
by 'Service Agents.' A third entity, called a 'Directory Agent'
provides scalability to the protocol.
The User Agent issues a 'Service Request' (SrvRqst) on behalf of the
client application, specifying the characteristics of the service
which the client requires. The User Agent will receive a Service
Reply (SrvRply) specifying the location of all services in the
network which satisfy the request.
The Service Location Protocol framework allows the User Agent to
directly issue requests to Service Agents. In this case the request
is multicast. Service Agents receiving a request for a service which
they advertise unicast a reply containing the service's location.
+------------+ ----Multicast SrvRqst----> +---------------+
| User Agent | | Service Agent |
+------------+ <----Unicast SrvRply------ +---------------+
In larger networks, one or more Directory Agents are used. The
Directory Agent functions as a cache. Service Agents send register
messages (SrvReg) containing all the services they advertise to
Directory Agents and receive acknowledgements in reply (SrvAck).
These advertisements must be refreshed with the Directory Agent or
they expire. User Agents unicast requests to Directory Agents
Guttman Expires: 7 May 2001 [Page 3]
Internet Draft SLPv2 Revision November 2001
instead of Service Agents if any Directory Agents are known.
+-------+ -Unicast SrvRqst-> +-----------+ <-Unicast SrvReg- +--------+
| User | | Directory | |Service |
| Agent | | Agent | | Agent |
+-------+ <-Unicast SrvRply- +-----------+ -Unicast SrvAck-> +--------+
User and Service Agents discover Directory Agents three ways. They
issue a multicast Service Request for the 'Directory Agent' service
when they start up. Additionally, the Directory Agent sends an
unsolicited advertisement infrequently, which the User and Service
Agents listen for. Finally, SLP agents may discover DA addresses via
DHCP. In any case, the agents obtain a DA Advertisement (DAAdvert).
+---------------+ --Multicast SrvRqst-> +-----------+
| User or | <--Unicast DAAdvert-- | Directory |
| Service Agent | | Agent |
+---------------+ <-Multicast DAAdvert- +-----------+
Services are grouped together using 'scopes'. These are strings
which identify services which are administratively identified. A
scope could indicate a location, administrative grouping, proximity
in a network topology or some other category. Service Agents and
Directory Agents are always assigned a scope string.
A User Agent is normally assigned a scope string (in which case the
User Agent will only be able to discover that particular grouping of
services). This allows a network administrator to 'provision'
services to users. Alternatively, the User Agent may be configured
with no scope at all. In that case, it will discover all available
scopes and allow the client application to issue requests for any
service available on the network.
+---------+ Multicast +-----------+ Unicast +-----------+
| Service | <--SrvRqst-- | User | --SrvRqst-> | Directory |
| Agent | | Agent | | Agent |
| Scope=X | Unicast | Scope=X,Y | Unicast | Scope=Y |
+---------+ --SrvRply--> +-----------+ <-SrvRply-- +-----------+
In the above illustration, the User Agent is configured with scopes X
and Y. If a service is sought in scope X, the request is multicast.
If in scope Y, the request is unicast to the DA. If the request is
made in both scopes, the request must be both unicast and multicast.
SLP Agents MAY implement SLP authentication which allows agents to
verify digital signatures provided with DAAdverts and service
information advertised by Service Agents. SLP Agents SHOULD be
enabled to use IPsec to authenticate unicast SLP messages as
originating from authorized SA and DA hosts (see Section 15).
Guttman Expires: 7 May 2001 [Page 4]
Internet Draft SLPv2 Revision November 2001
3.1 SLP Message Types
SAs MUST accept multicast service requests and unicast service
requests. SAs MAY accept other requests (Attribute and Service Type
Requests). SAs MUST listen for multicast DA Advertisements.
In the absence of Multicast support, Broadcast MAY be used. The
location of DAs may be staticly configured, discovered using SLP as
described above, or configured using DHCP. If a message is too large,
it may be unicast using TCP.
DAs MUST support all these message types, but DA support is itself
optional to deploy on networks using SLP. UAs and SAs requirement
levels for different message types are described below.
+--------------+-------------+-----+-----+-------------------------+
| Message | Abbreviation| UA | SA | Purpose |
+--------------+-------------+-----+-----+-------------------------+
| Service | SrvReg | | MUST| Register a service loca-|
| Register | | | | tion and attrs with a DA|
+--------------+-------------+-----+-----+-------------------------+
| Service | SrvDereg | | MUST| Deregisters a service |
| Deregister | | | | from a DA. |
+--------------+-------------+-----+-----+-------------------------+
| Service | SrvAck | | MUST| Contains a DA's response|
| Acknowledge | | | | to SrvReg and SrvDereg. |
+--------------+-------------+-----+-----+-------------------------+
| Service | SrvRqst | MUST| MUST| Requests services which |
| Request | | | | match query criteria. |
+--------------+-------------+-----+-----+-------------------------+
| Service | SrvRply | MUST| MUST| Returns services which |
| Reply | | | | match query criteria. |
+--------------+-------------+-----+-----+-------------------------+
| DA Advertise-| DAAdvert | MUST| MUST| Contains location, DA |
| ment | | | | attributes and more. |
+--------------+-------------+-----+-----+-------------------------+
| SA Advertise-| DAAdvert | MAY | MUST| Contains location, SA |
| ment | | | | attributes and more. |
+--------------+-------------+-----+-----+-------------------------+
| Service Type | SrvTypeRqst | MAY | MAY | Get all available |
| Request | | | | service types. |
+--------------+-------------+-----+-----+-------------------------+
| Service Type | SrvTypeRply | MAY | MAY | Contains all available |
| Reply | | | | service types. |
+--------------+-------------+-----+-----+-------------------------+
| Attribute | AttrRqst | MAY | MAY | Get all attributes for |
| Request | | | | a particular service. |
+--------------+-------------+-----+-----+-------------------------+
| Attribute | AttrRply | MAY | MAY | Contains all attributes |
| Reply | | | | of a particular service.|
+--------------+-------------+-----+-----+-------------------------+
Guttman Expires: 7 May 2001 [Page 5]
Internet Draft SLPv2 Revision November 2001
4. Protocol Elements
All length fields in SLP messages are in network byte order.
4.1 SLP Message Header
SLP messages all begin with the following header:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Function-ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length, contd.|O|F|R| reserved |Next Ext Offset|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Extension Offset, contd.| XID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Language Tag Length | Language Tag \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Version: Set to 2
- Function-ID: See Section 3.1.
- Length: The number of bytes of the SLP message, header included.
- Flags: All but the following bits are reserved and MUST be 0.
(0x80) OVERFLOW is set when a message's length exceeds what can
fit into a datagram. See Section XXX.
(0x40) FRESH is set on every SrvReg.
(0x20) REQUEST MCAST is set when multicasting or broadcasting
requests.
- Next Extension Offset: Set to 0 unless extensions are used. The
first extension begins at 'offset' bytes, from the message's
beginning, after SLP message data. See Section XXX.
- XID: Set to a unique value for each unique request. See Section
XXX and Section XXX for the special case of unsolicited DAAdverts.
- Lang Tag Length: The length in bytes of the Language Tag field.
- Language Tag: Specifies the language of all humanly readable
strings in the message. [RFC3066]. See Section XXX.
4.2 Error Codes
If the Error Code in a SLP reply message is nonzero, the rest of the
message MAY be truncated. No data is necessarily transmitted or
should be expected after the header and the error code, except
possibly for some optional extensions to clarify the error, for
example as in section D.1.
Errors are only returned for unicast requests. Multicast requests
are silently discarded if they result in an error.
OK * 0 There was no error.
LANGUAGE_NOT_SUPPORTED 1 The request could not be processed
Guttman Expires: 7 May 2001 [Page 6]
Internet Draft SLPv2 Revision November 2001
due to the language selected. The
request may succeed if the default
lanugage 'en' is used.
PARSE_ERROR 2 The message fails to obey SLP syntax.
INVALID_REGISTRATION 3 A registered service has problems.
SCOPE_NOT_SUPPORTED * 4 The scope-list lacks a supported scope.
AUTHENTICATION_UNKNOWN * 5 The request includes an unsupported SLP
SPI.
AUTHENTICATION_ABSENT 6 An expected authentication block is
missing.
AUTHENTICATION_FAILED 7 A SrvReg or SrvDereg to a DA cannot
be authenticated.
VER_NOT_SUPPORTED * 9 Unsupported SLP version number.
INTERNAL_ERROR * 10 The DA (or SA) is too sick to respond.
DA_BUSY_NOW * 11 UA or SA SHOULD retry, using exponential
back off.
OPTION_NOT_UNDERSTOOD * 12 The DA (or SA) received an unknown
SLP option from the mandatory range
(see section XXX).
INVALID_UPDATE 13 A SrvReg without FRESH set is invalid.
MSG_NOT_SUPPORTED 14 The SA received an unsupported request.
REFRESH_REJECTED 15 The SA sent a SrvReg or partial SrvDereg
too frequently.
The possible return values for each SLP request message are listed,
except those marked with '*' above. Those can be returned in a reply
to any SLP request.
4.3 Strings
Syntax for string based protocol elements conform to ABNF [RFC2234]
and are encoded using UTF-8 [RFC2279]. Strings are not null
terminated and are always preceded by a two byte unsigned length
field indicating the number of bytes which follow.
A List is a comma delimited set of strings whose syntax is:
list = null / slist
null = ; Null indicates no characters at all, an empty list.
slist = string / string ',' slist
string = ; Allowable strings depend on the List
unsafe = ',' / NULL
escape = "\" HEXDIG HEXDIG
Any unsafe character in a string component of a string list must be
replaced by an escaped hexadecimal UTF-8 value (ie. "\2c" for ',').
White spaces in strings are not elided for the purposes of string
comparison. That is, "string1 " != " string1" != "string1" and
"string1" is a member of "string1, string2, string3" but "string2" is
not.
Guttman Expires: 7 May 2001 [Page 7]
Internet Draft SLPv2 Revision November 2001
4.3.1 Previous Responder List
This is a List (See section 2.1) of dotted decimal notation IPv4
addresses.
When SLP SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast,
they SHOULD contain a Previous Responders List (see Section 4.3.1) of
all responders the UA has received replies from. Each responder's IP
address (in dotted decimal form) is added to form the new List.
Any DA or SA which sees its address in the <PRList> SHOULD NOT
respond to the request.
The message SHOULD be retransmitted until the <PRList> causes no
further responses to be elicited or the previous responder list and
the request will not fit into a single datagram or until
CONFIG_MC_MAX seconds elapse.
4.3.2 Service Type String
The service type string is used as a parameter in SrvRqst messages to
select a type of service, and in SrvReg messages to identify the
service type of an advertised service. The syntax of the service
type string is:
service-type = generic-uri-scheme / service-scheme
generic-uri-scheme = ALPHA *( alpha / digit / '+' / '-' / '.' )
service-scheme = "service:" type ['.' na ] [':' type ]
type = 1*(alpha / digit / '+' / '-' )
na = 1*(alpha / digit / '+' / '-' )
Service type string match each other with case insensitive string
comparison. A complication in comparing service types are abstract
service types [RFC2609]. These have the form:
"service:<abstract-type>:<concrete-type>".
The service type string "service:<abstract-type>" matches all
services of that abstract type. If the concrete type is included
also, only these services match the request.
Example: "service:a" matches "service:a" and "service:a:b".
A further complication in comparing service type strings are naming
authority strings. The service: URL scheme syntax allows the first
type listed after the 'service:' scheme to be followed by a '.' and a
Naming Authority string. Only service types with the same naming
authority match.
Example: "service:a.na" matches "service:a.na" and "service:a.na:b"
but it does not match "service:a" or "service:a:b" since the naming
Guttman Expires: 7 May 2001 [Page 8]
Internet Draft SLPv2 Revision November 2001
authority is different.
Naming authorities are used to define Service Types which are
proprietary, experimental or for private use. Naming authorities
SHOULD NOT be used (that is, one has to have a very good reason not
register service types with IANA as described in [RFC2609]).
4.3.3 Scope List
The primary use of Scopes is to provide the ability to create
administrative groupings of services. A set of services may be
assigned a scope by network administrators.
All requests and services are scoped. The two exceptions are
SrvRqsts for "service:directory-agent" and "service:service-agent".
SLP messages besides these which fail to contain a scope that the
receiving Agent is configured to use are dropped (if the request was
multicast) or a SCOPE_NOT_SUPPORTED error is returned (if the request
was unicast).
Scope Lists in SLPv2 have the following grammar:
scope-list = scope-val / scope-val `,' scope-list
scope-val = 1*safe
safe = ; Any character except reserved.
reserved = `(' / `)' / `,' / `' / `!' / `<' / `=' / `>' / `~' /
CTL / `;' / `*' / `+'
escape-val = `' HEXDIG HEXDIG
Scopes which include any reserved characters must replace the escaped
character with the escaped-val format.
The default value for the <scope-list> is "DEFAULT". Scope
configuration rules are described in Section 8.
4.3.4 Attribute list
A service advertisement is often accompanied by Service Attributes.
These attributes are used by UAs in Service Requests to select
appropriate services.
The allowable attributes which may be used are typically specified by
a Service Template [RFC2609] for a particular service type.
Services which are advertised according to a standard template SHOULD
register all service attributes which the standard template requires.
An attribute list is a string encoding of the attributes of a
service. The following ABNF [RFC2234] grammar defines attribute
lists:
Guttman Expires: 7 May 2001 [Page 9]
Internet Draft SLPv2 Revision November 2001
attr-list = attribute / attribute `,' attr-list
attribute = `(' attr-tag `=' val-list `)' / attr-tag
val-list = attr-val / attr-val `,' val-list
attr-tag = 1*safe-tag / nonstd-tag
nonstd-tag = "x-" enum `-' 1*safe-tag
enum = 1*DIGIT
; The <enum> field corresponds to an Enterprise
; Number registered with IANA. [IANA] Using this
; prefix avoids collisions in interpretation of
; nonstandard attribute name.
attr-val = intval / strval / boolval / opaque
intval = [-]1*DIGIT
strval = 1*safe-val
boolval = "true" / "false"
opaque = "FF" 1*escape-val
safe-val = ; Any character except reserved.
safe-tag = ; Any character except reserved, '*' and bad-tag.
reserved = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' /
`~' / CTL
escape-val = `\' HEXDIG HEXDIG
bad-tag = CR / LF / HTAB / `_'
The <attr-list>, if present, MUST be scanned prior to evaluation for
all occurrences of the escape character `'. Reserved characters MUST
be escaped (other characters MUST NOT be escaped). All escaped
characters must be restored to their value before attempting string
matching. For Opaque values, escaped characters are not converted -
they are interpreted as bytes.
Boolean Strings which have the form "true" or "false" can
only take one value and may only be compared with
'='. Booleans are case insensitive when compared.
Integer Strings which take the form [-] 1*<digit> and fall
in the range "-2147483648" to "2147483647" are
considered to be Integers. These are compared using
integer comparison.
String All other Strings are matched using strict lexical
ordering.
Opaque Opaque values are sequences of bytes. These are
distinguished from Strings since they begin with
the sequence "FF". This, unescaped, is an illegal
UTF-8 encoding, indicating that what follows is a
sequence of bytes expressed in escape notation which
constitute the binary value. For example, a '0' byte
is encoded "FF 0".
A string which contains escaped values other than from the reserved
set of characters is illegal.
Guttman Expires: 7 May 2001 [Page 10]
Internet Draft SLPv2 Revision November 2001
A keyword has only an <attr-tag>, and no values. Attributes can have
one or multiple values. All values are expressed as strings.
When values have been advertised by a SA or are registered in a DA,
they can take on implicit typing rules for matching incoming
requests.
Stored value types must be consistent, i.e., x=4,true,sue,\ff\00\00
is disallowed.
4.3.5 Attribute Tag lists
A List (see Section 2.1) of attribute tags. The attribute tag must
be encoded to escape reserved characters (see Section 6.1).
4.3.6 SLP SPI String
A List (see Section 2.1) of security parameter identifiers.
The SLP Security Parameters Index (SPI) string identifies the key
length, algorithm parameters and keying material to be used by agents
to verify the signature data in the Structured Authentication Block.
The SLP SPI string has the same grammar as the <scope-val> defined in
Section 6.4.1. SPIs deployed in a site MUST be unique.
4.4 URL Entry
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Lifetime | URL Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|URL len, contd.| URL (variable length) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# of URL auths | Auth. blocks (if any) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SLP stores URLs in protocol elements called URL Entries, which
associate a length, a lifetime, and possibly authentication
information along with the URL.
Authentication blocks are included depending on which SLP SPI strings
are associated with the message. In a SrvRqst or SrvRply, a single
SLP SPI string MAY be present. If no SLP SPI was included in the
request, no Authentication Blocks are returned in the reply. In a
SrvReg, multiple SLP SPIs MAY be present. The SA includes one
Authentication block per SLP SPI in the list. URL Authentication
Blocks are defined in Section 9.2.1.
Guttman Expires: 7 May 2001 [Page 11]
Internet Draft SLPv2 Revision November 2001
5. Required Features
This section lists requirements for any conforming implementation of
SLP. All requirements are identified by a letter (U, S or D, for UA,
SA or DA requirement) and a number, throughout this specification.
A minimal implementation may consist of either a UA or SA or both. A
DA is not required for SLP to function, but if it is present, the UA
and SA MUST interact with it as defined below.
A UA MUST be able to
U1. issue SrvRqst messages
U2. interpret SrvRply messages
U3. unicast requests to DAs if one is available (in the desired
scope) using UDP
U4. multicast requests if no DA is available (in the desired scope)
U5. perform DA discovery initially, then either periodically or
passively if no DA is known. The UA MUST be able to interpret
DAAdvert messages.
U6. be configured with a scope list and a list of DA locations.
A SA MUST be able to
S1. advertise a set of services
S2. receive and process unicast and multicast SrvRqsts. A SA which
offers no services with attributes need not process <predicates>.
(See Section 6.1)
S3. send SrvRply messages in response to SrvRqsts
S4. send SAAdvert messages in response to SrvRqsts
S5. perform DA discovery initially, then either periodically or
passively. The SA MUST be able to interpret SAAdvert messages
S6. register all currently advertised services with DAs as they are
discovered, then periodically if appropriate, before they expire.
S7. deregister advertised services with DAs if the services are no
longer available.
S8. be configured with a scope list and a list of DA locations.
A DA MUST
D1. receive and process unicast SrvRqst messages
D2. send SrvRply messages in response to SrvRqsts.
D3. receive and process multicast SrvRqst messages for service type
"service:directory-agent"
D4. unicast DAAdverts in response to these requests
D5. multicast DAAdverts initially and periodically
D6. process SrvReg messages and cache these services
D7. expire cached services when lifetimes expire
D8. process SrvDereg messages and remove cached services
D9. receive and process SrvTypeRqst messages
D10. send SrvTypeRply in response to SrvTypeRqsts
D11. receive and process AttrRqst messages
D12. send AttrRply messages in response to AttrRqsts
Guttman Expires: 7 May 2001 [Page 12]
Internet Draft SLPv2 Revision November 2001
5.1 Transport of SLP messages
Messages in SLP can be sent using four different transport
algorithms:
(1) Multicast requests soliciting unicast replies (2) Unicast UDP
requests soliciting unicast UDP replies (3) TCP requests
soliciting TCP replies (4) Multicast unsolicited announcements
In each case:
The reserved listening port for SLP is 427, for both UDP and TCP.
This is the destination port for all SLP messages. SLP messages
MAY be transmitted on an ephemeral port. Replies and
acknowledgements are sent to the port from which the request was
issued.
The Previous Responder List is used to provide a very limited form
of reliable multicast. By default, this list is empty.
Retransmitted requests use the same XID. This facillitates a DA or
SA to briefly cache its reply to the original request and then
send it again, should a duplicate request arrive. XIDs SHOULD be
randomly chosen to avoid duplicate XIDs in requests if UAs restart
frequently.
UDP message transmission
The default maximum transmission unit for UDP messages is 1400
bytes excluding UDP and other headers. Requests sent using UDP
MUST NOT exceed 1400 bytes. If a SLP reply message does not fit
into a UDP datagram it MUST be truncated to fit, and the OVERFLOW
flag is set in the reply message.
A UA which receives a truncated message MAY open a TCP connection
(see section 5.1.3) with the DA or SA and retransmit the request,
using the same XID. It MAY also attempt to make use of the
truncated reply or reformulate a more restrictive request which
will result in a smaller reply.
Multicast UDP transmission
SLP Requests messages are multicast to The Administratively Scoped
SLP Multicast [RFC2365] address, which is 239.255.255.253. The
default TTL to use for multicast is 255. In isolated networks,
broadcasts will work in place of multicast. To that end, SAs
SHOULD and DAs MUST listen for broadcast Service Location messages
at port 427.
Guttman Expires: 7 May 2001 [Page 13]
Internet Draft SLPv2 Revision November 2001
5.1.1 Multicast requests
Multicast messages MUST set the RQST Flag in the SLP header.
Multicast requests are used in three cases:
- UAs and SAs MUST support Active DA discovery (see Section XXX).
- UAs MUST support Active SA discovery (see Section XXX).
- UAs MUST be able to multicast SrvRqst messages to SAs, who MUST be
prepared to receive and process them.
One or more replies may be sent via unicast UDP. Errors are not
returned in response to multicast messages, only non-error, non-zero
results. The one exception to this is a multicast AttrRqst for a
service s registered without any attributes. A multicast AttrRqst
for s will result in a unicast AttrRply with a NULL attribute list.
SAs MUST accept multicast requests and unicast requests both. The SA
can distinguish between them by whether the REQUEST MCAST flag is set
in the SLP Message header. DAs MUST accept multicast requests as
part of DA discovery (see Section 9), otherwise they accept unicast
requests.
Multicast requests SHOULD be reissued over CONFIG_MC_MAX seconds
until a result has been obtained. Retransmission is not required if
the requesting agent is prepared to use the 'first reply' instead of
'as many replies as possible within a bounded time interval.' The
initial retransmission occurs after a CONFIG_RETRY wait period.
Retransmissions MUST be made with exponentially increasing wait
intervals (doubling the wait each time).
The message SHOULD be retransmitted until no further responses are
elicited (see Section 4.3.1) or until CONFIG_MC_MAX seconds elapse.
5.1.2 Unicast requests
Unicast requests to a DA or SA should be retransmitted until either a
response (which might be an error) has been obtained, or for
CONFIG_RETRY_MAX seconds. The initial retransmission occurs after a
CONFIG_RETRY wait period. Retransmissions MUST be made with
exponentially increasing wait intervals (doubling the wait each
time).
5.1.3 TCP requests
A SrvReg or SrvDeReg may be too large to fit into a datagram. To
send such large SLP messages, a TCP (unicast) connection MUST be
established.
To avoid the need to implement TCP, one MUST insure that:
Guttman Expires: 7 May 2001 [Page 14]
Internet Draft SLPv2 Revision November 2001
- UAs never issue requests larger than the Path MTU. SAs can omit
TCP support only if they never have to receive unicast requests
longer than the path MTU.
- UAs can accept replies with the 'OVERFLOW' flag set, and make use
of the first result included, or reformulate the request.
- Ensure that a SA can send a SrvRply, SrvReg, or SrvDeReg in a
single datagram. This means limiting the size of URLs, the number
of attributes and the number of authenticators transmitted.
DAs MUST be able to respond to UDP and TCP requests, as well as
multicast DA Discovery SrvRqsts. SAs MUST be able to respond to TCP
unless the SA will NEVER receive a request or send a reply which will
exceed a datagram in size (e.g., some embedded systems).
A TCP connection MAY be used for a single SLP transaction, or for
multiple transactions. Since there are length fields in the message
headers, SLP Agents can send multiple requests along a connection and
read the return stream for acknowledgments and replies.
The initiating agent SHOULD close the TCP connection. The DA SHOULD
wait at least CONFIG_CLOSE_CONN seconds before closing an idle
connection. DAs and SAs SHOULD close an idle TCP connection after
CONFIG_CLOSE_CONN seconds to ensure robust operation, even when the
initiating agent neglects to close it. See Section 13 for timing
rules.
5.1.4 Multicast announcement
Unsolicited DAAdvert messages are sent initially and periodically
sent by DAs via multicast. The XID in the message header is set to 0
in this case. See Section XXX.
6. Required messages
6.1 Service Request
This is the primary request message in SLP.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvRqst = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <PRList> | <PRList> (Section 4.3.1) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <service-type> | <service-type> (Section 4.3.2)\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> (Section 4.3.3) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Guttman Expires: 7 May 2001 [Page 15]
Internet Draft SLPv2 Revision November 2001
| length of predicate string | Service Request <predicate> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <SLP SPI> string | <SLP SPI> (Section 4.6) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The <PRList> (see Section 4.3.1) and <SLP SPI> (see Section 4.6) MAY
be 0 length.
The <service-type> (see Section 4.3.2) MUST NOT be 0 length. It
determines what the query is for. If the <service-type> is set to
"service:directory-agent", DAs respond to the SrvRqst with a DAAdvert
(see Section 9). If the <service-type> is set to "service:service-
agent", SAs respond with a SAAdvert (see Section SADISC). All other
SrvRqst messages elicit a SrvRply.
The <scope-list> (see Section 4.3.3) MUST NOT be 0 length, except for
DA or SA discovery (see Sections 9 and 10).
The <predicate> MAY be 0 length - in which case it matches all
services of the specified type in the specified scope.
The <predicate>, if present, is compared to each registered service,
such that the language of the request (ignoring the dialect part of
the Language Tag) matches the advertised service. Matching services
are returned in the reply message.
The form of the <predicate> is a LDAPv3 search filter [RFC2254], with
certain restrictions. A DA MUST accept any search filter, excluding
those with extensible matching rules. A SA MAY accept only simple
filters, (otherwise it accepts search filters as a DA would). A UA
SHOULD send only simple filters. The ABNF [RFC2234] for a simple
filter is:
simple-filter = conjoin / term
conjoin = "(&" term-list ")"
term-list = term term-list / term
term = "(" tag filtertype item ")" / "(" tag "=*)"
; The "=*" term tests if the attribute is present.
tag = 1*tag-safe
filtertype = "=" / "~=" / ">=" / "<="
; equal approx greater less
item = value / substring
; substring matching is only supported
value = 1*val-safe
substring = [value] any [value]
any = "*" *(value "*")
tag-unsafe = "=" / ">" / "<" / "~" / "(" / "\" / %x00
tag-safe = ; All UTF-8 characters are included except those in
; tag-unsafe. those must be escaped.
val-unsafe = "*" / "(" / ")" / "\" / %x00
val-safe = ; All UTF-8 characters are included except those in
Guttman Expires: 7 May 2001 [Page 16]
Internet Draft SLPv2 Revision November 2001
; val-unsafe. those must be escaped.
escaped = "\" HEXDIG HEXDIG
For equals and approx filters, or any string including a wildcard
"*", case insensitive string matching is done. Tag string matching
is also case insensitive.
For ordered string matching, values are matched using an implicit
type system, if no Service Template [RFC2609] is available.
Values of [-]1*DIGIT are assumed to be integers, so a service with
attribute list "(x=12),(y=-55)" would match the filter "(&(x>6)(y<-
44))". Note that integers do not match strings: the search
filter "(x=34*)" matches an attribute list '(x=34foo)', but not
'(x=3432)' since the first value is a String while the second value
is an Integer.
If the attribute in the filter has been registered with multiple
values, the filter is compared to each value and the results are ORed
together, i.e., "(x=3)" matches a registration of (x=1,2,3);
"(!(Y=0))" matches (y=0,1). Keywords (i.e., attributes without
values) are matched with a "presence" filter, as in "(keyword=*)".
Possible error results (in SrvRply, SAAdvert or DAAdvert) include:
LANGUAGE_NOT_SUPPORTED
When the <service-type> and <scope-list> match, the <predicate> is
not null, but no services are advertised in the language specified
in the language tag.
PARSE_ERROR
If <service-type> or <scope-list> is missing. If the header or
any field is malformed. If a predicate value includes a '*'
without using an '=' filterop.
MSG_NOT_SUPPORTED
If an SA which only accepts simple search filters receives a
unicast SrvRqst which includes a complex search filter.
6.2 Service Reply
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvRply = 2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | URL Entry count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <URL Entry 1> ... <URL Entry N> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The service reply contains zero or more URL entries (see Section
4.4). A service reply with zero URL entries MUST be returned in
response to a unicast Service Request, if no matching URLs are
Guttman Expires: 7 May 2001 [Page 17]
Internet Draft SLPv2 Revision November 2001
present.
If the reply overflows, the UA MAY simply use the first URL Entry in
the list. A URL obtained by SLP may not be cached longer than
Lifetime seconds, unless there is a URL Authenticator block present.
In that case, the cache lifetime is indicated by the Timestamp in the
URL Authenticator (see Section 9.2).
If a SrvRply is sent by UDP, a URL Entry MUST NOT be included unless
it fits entirely without truncation.
6.3 Service Registration
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvReg = 3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <URL-Entry> (Section 4.3.4) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of service type string | <service-type> (Section 4.3.1)\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> (Section 4.3.2) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of attr-list string | <attr-list> (Section 4.3.4) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# of AttrAuths |(if present) Attribute Authentication Blocks...\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Lifetime of the <URL-Entry> defines how long a DA can cache the
registration. SAs SHOULD reregister before this lifetime expires
(but SHOULD NOT more often than once per second). The Lifetime MAY
be set to any value between 0 and 0xffff (maximum, around 18 hours).
Long-lived registrations remain stale longer if the service fails and
the SA does not deregister the service.
The <service-type> defines the service type of the URL to be
registered, regardless of the scheme of the URL. The <scope-list>
MUST contain the names of all scopes configured for the SA.
The <attr-list>, if present, specifies the attributes and values to
be associated with the URL by the DA.
A SA configured with the ability to sign service registrations MUST
sign the <URL-Entry>s and <attr-list> using each of the keys it is
configured to use. The SA supplies a SLP SPI in each authentication
block indicating the SLP SPI configuration required to verify the
digital signature. The format of the digital signatures used is
defined in section 9.2.1.
The FRESH flag MUST be set on all registrations. This registration
Guttman Expires: 7 May 2001 [Page 18]
Internet Draft SLPv2 Revision November 2001
will replace any previous registration for the same URL in the same
language.
6.4 Service Acknowledgment
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvAck = 5) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A DA returns a SrvAck to an SA after a SrvReg or SrvDereg. It
carries only a two byte Error Code (see Section 7).
Possible errors in response to SrvReg and SrvDereg messages.
AUTHENTICATION_ABSENT
Subsequent registrations and deregistrations of previously
registered services MUST contain the same list of SLP SPIs as
previous ones or else DAs will reject them.
AUTHENTICATION_FAILED
Registrations and deregistrations including an authentication
block which the DA cannot verify are rejected.
REFRESH_REJECTED
If the FRESH flag is not set a DA MAY reject a SrvReg. If a
SrvDereg includes a tag list, a DA MAY reject it.
INVALID_REGISTRATION
The SrvReg has problems like a zero lifetime or an omitted
Language Tag.
6.5 Directory Agent Advertisement
The DAAdvert is used for DA Discovery (see Section 9).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = DAAdvert = 8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | DA Stateless Boot Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DA Stateless Boot Time, contd. | Length of URL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ URL \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <scope-list> | <scope-list> (Section 4.3.2) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <attr-list> | <attr-list> (Section 4.3.4) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Guttman Expires: 7 May 2001 [Page 19]
Internet Draft SLPv2 Revision November 2001
| Length of <SLP SPI> List | <SLP SPI> List (Section 4.6) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # Auth Blocks | Authentication block (if any) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Code is set to 0 when the DAAdvert is multicast. If the
DAAdvert is being returned due to a unicast SrvRqst (ie. a request
without the REQUEST MCAST flag set) the DA returns the same errors a
SrvRply would.
The <scope-list> of the SrvRqst must either be omitted or include a
scope which the DA supports.
The DA Stateless Boot Timestamp indicates the state of the DA (see
Section 9).
The DA MAY include a list of its attributes in the DAAdvert. This
list SHOULD be kept short, as the DAAdvert must fit into a datagram
in order to be multicast. See Section DAATTRS.
The URL is "service:directory-agent://"<addr> of the DA, where <addr>
is the dotted decimal numeric address of the DA. The <scope-list> of
the DA MUST NOT be NULL.
The <SLP SPI> List format of and use of DAAdvert signatures is
defined in Section 9.1.
6.6. Service Agent Advertisement
The SAAdvert is used by UAs to accumulate information about SAs on
the network, see Section SADISC.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SAAdvert = 11) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of URL | URL \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <scope-list> | <scope-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <attr-list> | <attr-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # auth blocks | authentication block (if any) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SA responds only to multicast SA discovery requests which
- either have an empty <scope-list> or one of the SA's scopes
- have <service-type> set to "service:service-agent".
- if a <predicate> is included, the SA must match it against its
attributes.
Guttman Expires: 7 May 2001 [Page 20]
Internet Draft SLPv2 Revision November 2001
The SAAdvert MAY include a list of attributes the SA supports. This
attribute list SHOULD be kept short so that the SAAdvert will not
exceed the path MTU in size. The <predicate> in a SrvRqst for
service type "service:service-agent" must match the SA's attributes
in order for the SA to send an SAAdvert reply.
The URL is "service:service-agent://"<addr> of the SA, where <addr>
is the dotted decimal numeric address of the SA. The <scope-list> of
the SA MUST NOT be null.
7. Optional Features
7.1 SLP Extensions
The format of a Service Location Extension is:
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 \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If an extension offset is specified, and an extension is not included
in the request, the receiver MUST respond with a PARSE_ERROR (if a
unicast request).
Extension IDs are assigned in the following way:
0x0000-0x3FFF Standardized. Optional to implement.
Ignore if unrecognized.
0x4000-0x7FFF Standardized. Mandatory to implement.
A UA or SA which receives this option in a reply and does not
understand it MUST silently discard the reply. A DA or SA which
receives this option in a request and does not understand it MUST
return an OPTION_NOT_UNDERSTOOD error.
0x8000-0x8FFF For private use, not standardized. Optional to
implement.
Ignore if unrecognized.
0x9000-0xFFFF Reserved.
The three byte offset to next extension indicates the position of the
next extension as offset from the beginning of the SLP message. The
offset value is 0 if there are no extensions following the current
extension. If the offset is 0, the length of the current Extension
Data is determined by subtracting total length of the SLP message as
given in the SLP message header minus the offset of the current
extension.
Section IANA defines procedures for specifying new SLP extensions.
Guttman Expires: 7 May 2001 [Page 21]
Internet Draft SLPv2 Revision November 2001
7.2 Authentication Blocks
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Structure Descriptor | Authentication Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLP SPI String Length | SLP SPI String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Structured Authentication Block ... \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authentication blocks are returned with certain SLP messages to
verify that the contents have not been modified, and have been
transmitted by an authorized agent. The authentication data
(contained in the Structured Authentication Block) is typically case
sensitive. Even though SLP registration data (e.g., attribute
values) are typically are not case sensitive, the case of the
registration data has to be preserved by the registering DA so that
UAs will be able to verify the data used for calculating digital
signature data.
The Block Structure Descriptor (BSD) identifies the format of the
Authenticator which follows. BSDs 0x0000-0x7FFF will be maintained
by IANA. BSDs 0x8000-0x8FFF are for private use.
The Authentication Block Length is the length of the entire block,
starting with the BSD.
The Timestamp is the time that the authenticator expires (to prevent
replay attacks.) The Timestamp is a 32-bit unsigned fixed-point
number of seconds relative to 0h on 1 January 1970. SAs use this
value to indicate when the validity of the digital signature expires.
This Timestamp will wrap back to 0 in the year 2106. Once the value
of the Timestamp wraps, (after 06h28 and 16 seconds 5 February 2106)
the time at which the Timestamp is relative to resets (to that
epoch).
SLP SPI strings are defined in Section 4.3.6. An SLP SPI used for
BSD=0x0002 must not be the same as used for some other BSD.
All SLP agents MUST implement DSA [FIPS] (BSD=0x0002). SAs MUST
register services with DSA authentication blocks, and they MAY
register them with other authentication blocks using other
algorithms. SAs MUST use DSA authentication blocks in SrvDeReg
messages and DAs MUST use DSA authentication blocks in unsolicited
DAAdverts.
The sections below define how to calculate the value to apply to the
Guttman Expires: 7 May 2001 [Page 22]
Internet Draft SLPv2 Revision November 2001
algorithm identified by the BSD value. The components listed are
used as if they were a contiguous single byte aligned buffer in the
order given.
URL
16-bit Length of SLP SPI String, SLP SPI String.
16-bit Length of URL, URL, 32-bit Timestamp.
Attribute List
16-bit Length of SLP SPI String, SLP SPI String,
16-bit length of <attr-list>, <attr-list>, 32-bit Timestamp.
DAAdvert
16-bit Length of SLP SPI String, SLP SPI String, 32-bit DA
Stateless Boot Timestamp, 16-bit Length of URL, URL, 16-bit Length
of <attr-list>, <attr-list>, 16-bit Length of DA's <scope-list>,
DA's <scope-list>, 16-bit Length of DA's supported <SLP SPI List>,
DA's <SLP SPI List>,32-bit Timestamp.
SAAdvert
16-bit Length of SLP SPI String, SLP SPI String, 16-bit Length of
URL, URL, 16-bit Length of <attr-list>, <attr-list>, 16-bit Length
of <scope-list>, <scope-list>, 32-bit Timestamp.
BSD=0x0002 is defined to be DSA with SHA-1. The signature
calculation is defined by [FIPS]. The signature format conforms to
that in the X.509 v3 certificate: (1). The signature algorithm
identifier (an OID), (2). The signature value (an octet string) and
(3). The certificate path. All data is represented in ASN.1
encoding:
id-dsa-with-sha1 ID ::= {
iso(1) member-body(2) us(840) x9-57 (10040)
x9cm(4) 3 }
i.e., the ASN.1 encoding of 1.2.840.10040.4.3 followed immediately
by:
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
i.e., the binary ASN.1 encoding of r and s computed using DSA and
SHA-1. Following this is a X.509 certificate path as per [ISO].
Authentication Blocks for BSD=0x0002 have the following format. In
the future, BSDs may be assigned which have different formats.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Guttman Expires: 7 May 2001 [Page 23]
Internet Draft SLPv2 Revision November 2001
| ASN.1 encoded DSA signature \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.3 Service Type Request
The Service Type Request (SrvTypeRqst) allows a UA to discover all
types of service on a network.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvTypeRqst = 9) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of PRList | <PRList> (Section 4.3.1) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of Naming Authority | <na> (Section 4.3.2) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> (Section 4.3.3) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Naming Authority string, if present in the request, will limit
the reply to Service Type strings with the specified Naming
Authority. If the Naming Authority string is absent, the IANA
registered service types will be returned.
If the length of the Naming Authority is set to 0xFFFF, the Naming
Authority string is ignored and ALL Service Types are returned,
regardless of Naming Authority. PLEASE NOTE: This is an exception to
how string length fields are used elsewhere in the protocol!
7.4 Service Type Reply
The list includes all service types advertised by the DA (or SA, if
the SA supports this message).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvTypeRply = 10) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | length of <srvtype> List |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <srvtype> List (Section 4.3.2) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If a service type has a Naming Authority other than IANA it MUST be
returned explicitely (see Section 4.3.2).
Guttman Expires: 7 May 2001 [Page 24]
Internet Draft SLPv2 Revision November 2001
7.5 Attribute Request
The Attribute Request (AttrRqst) allows a UA to discover attributes
of a given service (by supplying its URL). This information is also
available by using the Attrlist Extension to the SrvRqst [RFC3059].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = AttrRqst = 6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of PRList | <PRList> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of URL | URL \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> (Section 4.3.3) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <tag-list> string | <tag-list> (Section 4.3.5) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <SLP SPI> string | <SLP SPI> (Section 4.3.6) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The <tag-list> indicates the attributes to return in the AttrRply.
If <tag-list> is omitted, all attributes are returned. The <tag-
list> MUST be omitted and a full URL MUST be included when attributes
when a SLP SPI List string is included, otherwise the DA will reply
with an AUTHENTICATION_FAILED error.
7.6 Attribute Reply
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = AttrRply = 7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | length of <attr-list> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <attr-list> (Section 4.3.4) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# of AttrAuths | Attribute Authentication Block (if present) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute replies SHOULD be returned with the original case of the
string registration intact, as they are likely to be human readable.
Only one copy of each attribute tag or String value should be
returned, arbitrarily choosing one version (with respect to upper and
lower case and white space internal to the strings): Duplicate
attributes and values SHOULD be removed. An arbitrary version of the
string value and tag name is chosen for the merge. For example:
"(A=a a,b)" merged with "(a=A A,B)" may yield "(a=a a,B)".
Guttman Expires: 7 May 2001 [Page 25]
Internet Draft SLPv2 Revision November 2001
7.7 Service Deregistration
A DA deletes a service registration when its Lifetime expires.
Services SHOULD be deregistered when they are no longer available,
rather than leaving the registrations to time out.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvDeReg = 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <scope-list> | <scope-list> (Section 4.3.2) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URL Entry (Section 4.4) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <tag-list> | <tag-list> (Section 4.3.5) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The DA acknowledges a SrvDeReg with a SrvAck. Once the SA receives
an acknowledgment indicating success, the service and/or attributes
are no longer advertised by the DA. The DA deregisters the service or
service attributes from every scope specified in the SrvDeReg which
it was previously registered in, in every language.
The SA MUST deregister all services with the same scope list used to
register the service with a DA. If this is not done in the SrvDeReg
message, the DA returns a SCOPE_NOT_SUPPORTED error. The Lifetime
field in the URL Entry is ignored for the purposes of the SrvDeReg.
The <tag-list> MUST be sent as an empty list. DAs MUST accept non-
empty <tag-lists> for backward compatibility (see [SLPv2AS]).
Error codes which may result
AUTHENTICATION_FAILED
If the tag-list is non-zero for a SrvDereg of a service which was
registered using an Authentication Block. Or, if the SrvDereg
message fails to be verified by the DA.
AUTHENTICATION ABSENT
If the service to be deregistered was registered with an
authentication block or blocks, a URL authentication block for
each of the SLP SPIs registered MUST be included in the SrvDeReg.
8. Scope list configuration
The default scope list configuration for any agent is the string
"DEFAULT". All SLP Agents MUST support static configuration of a
scope list. Other mechanisms are optional. These options are in
prioritized order. If a static scope list exists, DHCP option 79 is
ignored, for example.
Guttman Expires: 7 May 2001 [Page 26]
Internet Draft SLPv2 Revision November 2001
Preference Mechanism Requirement level
(1) Static configuration of scope list MUST
(2) Static configuration of DAs * MUST
(3) DHCP SLP Scope configuration SHOULD
(4) DHCP SLP DA configuration * SHOULD
(5) Dynamic discovery (DAAdverts) ** MAY
(6) Dynamic discovery (SAAdverts) ** MAY
(7) Use of the scope "DEFAULT" MUST
(2) A SA or UA with a static configured list of DAs will unicast DA
Discovery messages (see Section 9) to the DAs on the list and create
a list of all scopes those DAs support. This forms the agent's scope
list.
(3) DHCP option 79 can explicitely configure a UA or SA's scope list.
[2610bis]
(4) DHCP option 78 can supply a list of DA locations. The UA or SA
acquires their scope list, as per (2), above. [2610bis]
(5) A UA or SA can use active and passive DA Discovery (see Section
9) to acquire a list of DAs. The combined list of their scopes forms
the agent's scope list.
(6) A UA can use active SA discovery (see Section 10) to obtain
SAAdverts from SAs on the network. The combined list becomes the
UA's scope list.
UAs can issue requests with any subset of scopes they are configured
with. It is left up to the implementator whether to enable clients
to synthesize their own scope lists (by using DA and SA discovery) or
only to support static and DHCP discovery.
9. Directory Agents
DAs cache service location and attribute information. They exist to
enhance the performance and scalability of SLP. Multiple DAs provide
further scalability and robustness of operation, since they can each
store service information for the same SAs, in case one of the DAs
fails.
A DA provides a centralized store for service information. This is
useful in a network with several subnets or with many SLP Agents.
The DA address can be dynamically configured with UAs and SAs using
DHCP, or by using static configuration.
SAs configured to use DAs with DHCP or static configuration MUST
unicast a SrvRqst to the DA, when the SA is initialized. The SrvRqst
omits the scope list and sets the service type of the request to
"service:directory-agent". The DA will return a DAAdvert with its
attributes, SLP SPI list, and other parameters which are essential
Guttman Expires: 7 May 2001 [Page 27]
Internet Draft SLPv2 Revision November 2001
for proper SA to DA communication.
Passive detection of DAs by SAs enables services to be advertised
consistently among DAs of the same scope. Advertisements expire if
not renewed, leaving only transient stale registrations in DAs, even
in the case of a failure of a SA.
A single DA can support many UAs. UAs send the same requests to DAs
that they would send to SAs and expect the same results. DAs reduce
the load on SAs, making simpler implementations of SAs possible.
UAs MUST be prepared for the possibility that the service information
they obtain from DAs is stale.
9.1 Directory Agent Rules
When DAs are present, each SA MUST register its services with DAs
that support one or more of its scope(s). After discovering a new
DA, a SA MUST wait a random time between 0 and CONFIG_REG_ACTIVE
seconds before registering their services.
When DAs are present, UAs MUST unicast requests to them in preference
to multicasting requests to SAs.
DAs MUST flush service advertisements once their lifetime expires or
their URL Authentication Block "Timestamp" of expiration is past.
9.2 Directory Agent Discovery
UAs and SAs discover DAs using static configuration, DHCP options 78,
79, by multicasting (or broadcasting) Service Requests using the
retransmission algorithm in Section 5.1.1, as per Section 9.3, or by
listening for unsolicited DAAdvert announcements, see Section 9.4.
UAs MUST support static configuration and active discovery, SAs in
addition MUST support passive DA discovery. UAs MAY support passive
DA discovery; if not they MUST periodically perform active DA
discovery (every CONFIG_DA_FIND seconds, but no more frequently).
9.3 Active DA discovery
DAs MUST respond to multicast and unicast SrvRqsts for service type
"service:directory-agent" if the predicate matches the attributes in
the DA's attribute list and (a) the scope list is omitted or (b) the
requests scope list includes one or more scopes the DA is configured
to use. DAs respond with a DAAdvert (see Section 5.5).
The <scope-list> MUST contain all scopes configured for the UA or SA
which is discovering DAs. If the UA or SA has not scope list,
however, the <scope-list> used in active DA discovery MAY be empty.
This allows the UA or SA to derive a scope list from DAAdverts it
Guttman Expires: 7 May 2001 [Page 28]
Internet Draft SLPv2 Revision November 2001
receives.
After a UA or SA restarts, its initial DA discovery request SHOULD be
delayed for some random time uniformly distributed from 0 to
CONFIG_START_WAIT seconds.
9.4 Passive DA discovery
A DA MUST multicast (or broadcast) an unsolicited DAAdvert every
CONFIG_DA_BEAT seconds. CONFIG_DA_BEAT SHOULD be specified to
prevent DAAdverts from using more than 1% of the available bandwidth.
An unsolicited DAAdvert has an XID of 0.
All UAs and SAs which receive the unsolicited DAAdvert SHOULD examine
its DA stateless Boot Timestamp. If it is set to 0, the DA is going
down and no further messages should be sent to it.
If a SA detects a DA it has never encountered (with a nonzero
timestamp,) the SA must register with it. SAs MUST examine the
DAAdvert's timestamp to determine if the DA has had a stateless
reboot since the SA last registered with it. If so it registers with
the DA. SAs MUST wait a random interval between 0 and
CONFIG_REG_PASSIVE before beginning DA registration.
9.5 DAAdvert Authentication
The SLP SPI List is the list of SPIs that the DA is capable of
verifying. SAs MUST NOT register services with authentication blocks
for those SLP SPIs which are not on the list. DAs will reject
service registrations which they cannot verify, returning an
AUTHENTICATION_UNKNOWN error.
The SLP SPI which is used to verify the DAAdvert is included in the
Authentication Block. When DAAdverts are multicast, they may have to
transmit multiple DAAdvert Authentication Blocks. If the DA is
configured to be able to generate signatures for more than one SPI,
the DA MUST include one Authentication Block for each SPI. If all
these Authentication Blocks do not fit in a single datagram (to
multicast or broadcast) the DA MUST send separate DAAdverts so that
Authentication Blocks for all the SPIs the DA is capable of
generating are sent.
If the DAAdvert is being sent in response to a SrvRqst, the DAAdvert
contains only the authentication block with the SLP SPI in the
SrvRqst, if the DA is configured to be able to produce digital
signatures using that SLP SPI. If the SrvRqst is unicast to the DA
(the REQUEST MCAST flag in the header is not set) and an unsupported
SLP SPI is included, the DA replies with a DAAdvert with the Error
Code set to an AUTHENTICATION_UNKNOWN error.
UAs SHOULD be configured with SLP SPIs that will allow them to verify
Guttman Expires: 7 May 2001 [Page 29]
Internet Draft SLPv2 Revision November 2001
DA Advertisements. If the UA is configured with SLP SPIs and
receives a DAAdvert which fails to be verified using one of them, the
UA MUST discard it.
9.6 Directory Agent Attributes
DAs may advertise attributes. One attribute is defined by SLPv2.
A potential scaling problem occurs in SLPv2 if SAs choose too low a
Lifetime. In this case, an onerous amount of reregistration occurs
as more services are deployed. SLPv2 allows DAs to control SAs
frequency of registration. A DA MAY reissue a DAAdvert with a new
set of attributes at any time, to change the reregistration behavior
of SAs. These apply only to subsequent registrations; existing
service registrations with the DA retain their registered lifetimes.
If the DAAdvert includes the attribute "min-refresh-interval" it MUST
be set to a single Integer value indicating a number of seconds. If
this attribute is present SAs MUST NOT refresh any particular service
advertisement more frequently than this value. If SrvReg or SrvDereg
for a particular service is received more often than the value for
the DA's advertised "min-refresh-interval" attribute the DA SHOULD
reject the message and return a REFRESH_REJECTED error in the SrvAck.
10. Service Agent Discovery
A User Agent MAY, in the absence of knowledge of DAs, and other scope
list configuration, obtain SAAdverts from SAs on the network. This
allows the UA to synthesize a scope list it can use to issue
requests. The SAAdverts may carry other information of potential use
(their location and attribute list, see Section 6.6).
A SA MAY be configured with attributes, and SHOULD support the
attribute 'service-type' whose value is all the service types of
services represented by the SA. SAs MUST NOT respond if the SrvRqst
predicate is not satisfied. For example, only SAs advertising 'nfs'
services SHOULD respond with a SAAdvert to a SrvRqst for service type
"service:service-agent" which includes a predicate "(service-
type=nfs)".
The SAAdvert contains one SAAdvert Authentication block for each SLP
SPI the SA can produce Authentication Blocks for. If the UA can
verify the Authentication Block of the SAAdvert, and the SAAdvert
fails to be verified, the UA MUST discard it.
11. Protocol Timing Defaults
Interval name Default Meaning
----------------- ------- ------------------------
CONFIG_MC_MAX 15 secs Max time to wait for a complete multicast
query response (all values.)
Guttman Expires: 7 May 2001 [Page 30]
Internet Draft SLPv2 Revision November 2001
CONFIG_START_WAIT 3 secs Wait to perform DA discovery on reboot.
CONFIG_RETRY 2 secs Wait interval before first retransmission
of multicast or unicast requests.
CONFIG_RETRY_MAX 15 secs Give up on unicast request retransmission.
CONFIG_DA_BEAT 3 hours DA Heartbeat, for emitting DAAdverts.
CONFIG_DA_FIND 900 secs Minimum wait interval before repeating
Active DA discovery.
CONFIG_REG_PASSIVE 1-3 secs Wait to register, on passive DA discovery.
CONFIG_REG_ACTIVE 1-3 secs Wait to register, on active DA discovery.
CONFIG_CLOSE_CONN 300 secs DAs and SAs close idle connections.
12. Optional Configuration
Broadcast Only
Any SLP agent SHOULD be configurable to use broadcast only.
Predefined DA
A UA or SA SHOULD be configurable to use a predefined DA.
No DA Discovery
The UA or SA SHOULD be configurable to ONLY use predefined and
DHCP-configured DAs and perform no active or passive DA discovery.
Multicast TTL
The default multicast TTL is 255. Agents SHOULD be configurable
to use other values. A lower value may result in UAs obtaining
different results for the identical requests depending on where
they are connected to the network.
Timing Values
Time values in Section 11 MAY be configurable.
Scopes
The Scope list string must be configurable.
DHCP Configuration
DHCP options 78 and 79 may be used to configure SLP. [2610bis]
Service Templates
Service Template UAs and SAs MAY be configured by using Service
Templates. These allow language translation, setting default
values and API error checking.
SLP SPI for service discovery
Agents SHOULD be configurable to support SLP SPIs using the
following parameters: BSD=2 (DSA with SHA-1) and a public key
identified by the SLP SPI String.
SLP SPI for Directory Agent discovery
Agents SHOULD be configurable to support SLP SPIs as above, to be
used when discovering DAs. This SPI SHOULD be sent in SrvRqsts to
discover DAs and be used to verify multicast DAAdvert messages.
SA and DA Private Key
SAs and DAs which can generate digital signatures require a
Private Key and a corresponding SLP SPI indentifier to include in
the Authentication Block. The SLP SPI identifies the Public Key
to use to verify the digital signature in the Authentication
Block.
Guttman Expires: 7 May 2001 [Page 31]
Internet Draft SLPv2 Revision November 2001
13. IANA Considerations
SLP includes four sets of identifiers which may be registered with
IANA. The policies for these registrations (See [RFC2434]) are noted
in each case.
The Block Structure Descriptor (BSD) identifies the format of the
Authenticator which follows. BSDs 0x8000-0x8FFF are for Private Use.
Further Block Structured Descriptor (BSD) values, from the range
0x0003-0x7FFF may be standardized in the future by submitting a
document which describes:
- The data format of the Structured Authenticator block.
- Which cryptographic algorithm to use (including a reference to a
technical specification of the algorithm.)
- The format of any keying material required for preconfiguring UAs,
DAs and SAs. Also include any considerations regarding key
distribution.
- Security considerations to alert others to the strengths and
weaknesses of the approach.
Both Cryptographic BSD numbers and new function-IDs (in the range
12-255), may be standardized by the method of IETF Consensus.
New SLP Extensions with types in the range 2-65535 may be registered
following review by a Designated Expert.
New error numbers in the range 15-65535 are assigned on the basis of
a Standards Action.
Protocol elements used with Service Location Protocol may also
require IANA registration actions. SLP is used in conjunction with
"service:" URLs and Service Templates [RFC2609]. These are
standardized by review of a Designated Expert and a mailing list (See
[RFC2609].)
14. Internationalization Considerations
SLP messages support the use of multiple languages by providing a
Language Tag field in the common message header (see Section 8).
Services MAY be registered in multiple languages. This provides
attributes so that users with different language skills may select
services interactively.
Attribute tags are not translated. Attribute values may be
translated unless the Service Template [RFC2609] defines the
attribute values to be 'literal'.
A service which is registered in multiple languages may be queried in
multiple languages. The language of the SrvRqst or AttrRqst is used
Guttman Expires: 7 May 2001 [Page 32]
Internet Draft SLPv2 Revision November 2001
to satisfy the request. If the requested language is not supported,
a LANGUAGE_NOT_SUPPORTED error is returned. SrvRply and AttrRply
messages are always in the same language of the request.
A DA or SA MAY be configured with translations of Service Templates
[RFC2609] for the same service type. This will allow the DA or SA to
translate a request (say in Italian) to the language of the service
advertisement (say in English) and then translate the reply back to
Italian. Similarly, a UA MAY use templates to translate outgoing
requests and incoming replies.
The dialect field in the Language Tag MAY be used: Requests which
can be fulfilled by matching a language and dialect will be preferred
to those which match only the language portion. Otherwise, dialects
have no effect on matching requests.
15. Security Considerations
Threat Assessment: If SLP is used without authentication of data
which is acquired, an attacker could reply with misrepresent
information about existing services or representing services which
are not what the user (or the administrator) expects, such as
services controlled by the attacker. This could potentially allow an
attacker to gain access to a user's private information, and make it
much easier to launch selective denial of service attacks.
Authentication of DAAdverts is especially important because UAs can
be trivially misled to beleive there are no services by a malicious
DA.
SLP authentication is associated with the data objects that SLP
carries: URL entries, attribute lists, DAAdverts and SAAdverts. The
reason that objects instead of communication are protected is that
service data can be stored by DAs and forwarded to UAs. UAs use
authentication as a mechanism (applied to a policy) to determine the
trustworthiness of data depending on the source of the data (the SA
in the case of service advertisements, the DA in the case of
DAAdverts).
A weakness in SLPv2 security is that negative replies (SrvAck, errors
in DAAdvert, SrvRply, AttrRply and SrvTypeRply) are not authorized.
An attacker's DA could interpose such a message and fool a UA or SA
into believing that a request to a DA failed when in fact it
succeeded.
IP Security [RFC2401] could be used to secure SLP if certain policies
and certificates are configured among hosts supporting SLP agents.
First, a set of 'authorized' SAs and DAs are selected and issued host
certificates, such that UAs and DAs can verify that the certificates
are valid and of the 'authorized' type. Unicast messages used in SLP
will establish security associations, but only with authorized SAs
and DAs. This allows all sensitive data in these messages (SrvReg,
Guttman Expires: 7 May 2001 [Page 33]
Internet Draft SLPv2 Revision November 2001
SrvDereg, SrvAck, SrvRply, AttrRply, SrvTypeRply) to be authenticated
by agents before being accepted. If confidentiality (which is not
provided in SLPv2) is desired the IP Encapsulating Security Payload
(ESP) [RFC2406] can be used for Service Location messages.
Note that use of IP security for SLP is not applied to multicast
messages. Only unicast 'reply' messages are authenticated according
to the filtering policy such that only hosts holding 'authorized'
certificates are appropriate to establish security associations for
the purpose of accepting SLP replies.
One side effect of this approach is that DAs must be trusted as much
as SAs (since IPsec only provides transport security, and DAs store
and forward data generated by SAs).
SLP is useful as a bootstrap protocol. It may be used in
environments in which no preconfiguration is possible. In such
situations, a certain amount of "blind faith" is required: Without
any prior configuration it is impossible to use any of the security
mechanisms described above.
References
[FIPS] National Institute of Standards and Technology. Digital
signature standard. Technical Report NIST FIPS PUB 186, U.S.
Department of Commerce, May 1994.
[IANA] http://www.iana.org/numbers.html
[ISO] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment
DAM 4 to ISO/IEC 9594-2, December 1996
ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment DAM
2 to ISO/IEC 9594-6, December 1996.
ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment DAM
1 to ISO/IEC 9594-7, December 1996.
ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment DAM
1 to ISO/IEC 9594-8, December 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2254] Howes, T., "The String Representation of LDAP Search
Filters", RFC 2254, December 1997.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of unicode and
Guttman Expires: 7 May 2001 [Page 34]
Internet Draft SLPv2 Revision November 2001
ISO 10646", RFC 2279, October 1998.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", RFC
2365, July 1998.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[RFC2401] Kent, S., Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security Payload
(ESP)", RFC 2406 November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434, October 1998.
[RFC2608] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service
Location Protocol version 2", RFC 2608, July 1999.
[RFC2609] Guttman, E., Perkins, C. and J. Kempf, "Service Templates
and service: Schemes", RFC 2609, June 1999.
[2610bis] Guttman, E., "DHCP Options for Service Location". A work in
progress.
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages",
RFC 3066, March 1995.
[SLPv2AS] Guttman, E., "Applicability Statement for SLPv2". A work in
progress.
Author's Contact Information
Erik Guttman Phone: +49 172 865 5497
Sun Microsystems, Inc. Fax: +49 7263 911 701
Eichhoelzelstr. 7 Email: Erik.Guttman@Sun.Com
74915 Waibstadt
Germany
Full Copyright Statement
Copyright (C) The Internet Society (2001). 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
Guttman Expires: 7 May 2001 [Page 35]
Internet Draft SLPv2 Revision November 2001
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
assigns. 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.
Table of Contents
Abstract . . . . . . . . . . . 1 6.6. Service Agent
Acknowledgements . . . . . . . 1 Advertisement . . . . . . 20
1. Introduction . . . . . . . 2 7. Optional Features . . . . . 21
2. Terminology and Conventions 2 7.1 SLP Extensions . . . . . . 21
3. Protocol Overview . . . . . 3 7.2 Authentication Blocks . . 22
3.1 SLP Message Types . . . . 5 7.3 Service Type Request . . . 24
4. Protocol Elements . . . . . 6 7.4 Service Type Reply . . . . 24
4.1 SLP Message Header . . . . 6 7.5 Attribute Request . . . . 25
4.2 Error Codes . . . . . . . 6 7.6 Attribute Reply . . . . . 25
4.3 Strings . . . . . . . . . 7 7.7 Service Deregistration . . 26
4.3.1 Previous Responder List 8 8. Scope list configuration . 26
4.3.2 Service Type . . . . . . 8 9. Directory Agent Discovery . 27
4.3.3 Scope List . . . . . . . 9 9.1 Directory Agent Rules . . 28
4.3.4 Attribute List . . . . . 9 9.2 Directory Agent Discovery 28
4.3.5 Attribute Tag list . . . 11 9.3 Active DA discovery . . . 28
4.3.6 SLP SPI . . . . . . . . 11 9.4 Passive DA discovery . . . 29
4.4 URL Entry . . . . . . . . 11 9.5 DAAdvert Authentication . 29
5. Required Features . . . . . 12 9.6 Directory Agent Attributes 30
5.1 Transport of SLP messages 13 10. Service Agent Discovery . 30
5.1.1 Multicast Requests . . . 14 11. Protocol Timing Defaults . 30
5.1.2 Unicast UDP Requests . . 14 12. Optional Configuration . . 31
5.1.3 TCP Requests . . . . . . 14 13. IANA Considerations . . . 32
5.1.4 Multicast Announcement . 15 14. Internationalization
6. Required Messages . . . . . 15 Considerations . . . . . . 32
6.1 Service Request . . . . . 15 15. Security Considerations . 33
6.2 Service Reply . . . . . . 17 References . . . . . . . . . . 34
6.3 Service Registration . . . 18 Author's Contact Information . 35
6.4 Service Acknowledgment . . 19 Full Copyright Statement . . . 35
6.5 Directory Agent
Advertisement . . . . . . 19
Guttman Expires: 7 May 2001 [Page 36]