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 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 SHOULD NOT respond to the request. The message SHOULD be retransmitted until the 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::". The service type string "service:" 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 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 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 , 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* 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 , 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 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 . (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 | (Section 4.3.1) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | (Section 4.3.2)\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | (Section 4.3.3) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Guttman Expires: 7 May 2001 [Page 15] Internet Draft SLPv2 Revision November 2001 | length of predicate string | Service Request \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of string | (Section 4.6) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The (see Section 4.3.1) and (see Section 4.6) MAY be 0 length. The (see Section 4.3.2) MUST NOT be 0 length. It determines what the query is for. If the is set to "service:directory-agent", DAs respond to the SrvRqst with a DAAdvert (see Section 9). If the is set to "service:service- agent", SAs respond with a SAAdvert (see Section SADISC). All other SrvRqst messages elicit a SrvRply. The (see Section 4.3.3) MUST NOT be 0 length, except for DA or SA discovery (see Sections 9 and 10). The MAY be 0 length - in which case it matches all services of the specified type in the specified scope. The , 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 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 and match, the is not null, but no services are advertised in the language specified in the language tag. PARSE_ERROR If or 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Section 4.3.4) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of service type string | (Section 4.3.1)\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | (Section 4.3.2) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of attr-list string | (Section 4.3.4) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |# of AttrAuths |(if present) Attribute Authentication Blocks...\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Lifetime of the 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 defines the service type of the URL to be registered, regardless of the scheme of the URL. The MUST contain the names of all scopes configured for the SA. The , 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 s and 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 | (Section 4.3.2) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of | (Section 4.3.4) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Guttman Expires: 7 May 2001 [Page 19] Internet Draft SLPv2 Revision November 2001 | Length of List | 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 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://" of the DA, where is the dotted decimal numeric address of the DA. The of the DA MUST NOT be NULL. The 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 | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # auth blocks | authentication block (if any) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The SA responds only to multicast SA discovery requests which - either have an empty or one of the SA's scopes - have set to "service:service-agent". - if a 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 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://" of the SA, where is the dotted decimal numeric address of the SA. The 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 , , 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 , , 16-bit Length of DA's , DA's , 16-bit Length of DA's supported , DA's ,32-bit Timestamp. SAAdvert 16-bit Length of SLP SPI String, SLP SPI String, 16-bit Length of URL, URL, 16-bit Length of , , 16-bit Length of , , 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 | (Section 4.3.1) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of Naming Authority | (Section 4.3.2) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | (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 List | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of URL | URL \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | (Section 4.3.3) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of string | (Section 4.3.5) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of string | (Section 4.3.6) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The indicates the attributes to return in the AttrRply. If is omitted, all attributes are returned. The 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (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 | (Section 4.3.2) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | URL Entry (Section 4.4) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of | (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 MUST be sent as an empty list. DAs MUST accept non- empty 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 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 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]