Internet Engineering Task Force Erik Guttman INTERNET DRAFT Charles Perkins 4 May 1998 Sun Microsystems John Veizades @Home Network Michael Day Intel Service Location Protocol draft-ietf-svrloc-protocol-v2-05.txt Status of This Memo This document is a submission by the Service Location Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the srvloc@srvloc.org mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To view the entire list of current Internet-Drafts, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. 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. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page i]
Internet Draft Service Location Protocol 4 May 1998 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Terminology 2 2.1. Notation Conventions . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview 3 4. URLs used with Service Location 4 4.1. Service: URLs . . . . . . . . . . . . . . . . . . . . . . 4 4.2. URL Entries . . . . . . . . . . . . . . . . . . . . . . . 6 5. Service Attributes 6 6. Required Features 8 6.1. Use of UDP, TCP, and Multicast . . . . . . . . . . . . . 9 6.1.1. UDP and Multicast Transmission of SLP Messages . 9 6.2. Use of TCP . . . . . . . . . . . . . . . . . . . . . . . 9 6.2.1. Retransmission of multicast messages . . . . . . 10 6.3. Strings in SLP messages . . . . . . . . . . . . . . . . . 11 7. Required SLP Messages 11 7.1. Service Request . . . . . . . . . . . . . . . . . . . . . 13 7.2. Service Reply . . . . . . . . . . . . . . . . . . . . . . 15 7.3. Service Registration . . . . . . . . . . . . . . . . . . 15 7.4. Service Acknowledgment . . . . . . . . . . . . . . . . . 16 7.5. Directory Agent Advertisement . . . . . . . . . . . . . . 17 7.6. Service Agent Advertisement . . . . . . . . . . . . . . . 17 8. Errors 18 9. Optional Features 19 9.1. Service Location Protocol Extension Options . . . . . . . 19 9.2. Authentication Blocks . . . . . . . . . . . . . . . . . . 20 9.2.1. MD5 with RSA in Authentication Blocks . . . . . . 21 9.2.2. DSA with SHA-1 in Authentication Blocks . . . . . 21 9.2.3. Keyed HMAC with MD5 in Authentication Blocks . . 21 9.3. Authentication of a SrvRply . . . . . . . . . . . . . . . 22 9.4. Optimizations with XIDs . . . . . . . . . . . . . . . . . 22 9.5. Service Registration Updates . . . . . . . . . . . . . . 22 9.6. Naming Authorities . . . . . . . . . . . . . . . . . . . 23 9.7. Tag Lists . . . . . . . . . . . . . . . . . . . . . . . . 23 Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page ii]
Internet Draft Service Location Protocol 4 May 1998 10. Optional SLP Messages 24 10.1. Service Type Request . . . . . . . . . . . . . . . . . . 24 10.2. Service Type Reply . . . . . . . . . . . . . . . . . . . 25 10.3. Attribute Request . . . . . . . . . . . . . . . . . . . . 25 10.4. Attribute Reply . . . . . . . . . . . . . . . . . . . . . 26 10.5. Attribute Request/Reply Examples . . . . . . . . . . . . 27 10.6. Service Deregistration . . . . . . . . . . . . . . . . . 28 11. Scopes 29 11.1. Scope Rules . . . . . . . . . . . . . . . . . . . . . . . 29 11.2. Administrative and User Configurable Scopes . . . . . . . 30 11.3. Protected Scopes . . . . . . . . . . . . . . . . . . . . 30 12. Directory Agents 31 12.1. Directory Agent Rules . . . . . . . . . . . . . . . . . . 31 12.2. Directory Agent Discovery . . . . . . . . . . . . . . . . 32 12.2.1. Active DA Discovery . . . . . . . . . . . . . . . 32 12.2.2. Passive DA Advertising . . . . . . . . . . . . . 33 12.3. Reliable Unicast to DAs . . . . . . . . . . . . . . . . . 33 12.4. DA Scope Configuration . . . . . . . . . . . . . . . . . 33 12.5. DAs and Authentication Blocks . . . . . . . . . . . . . . 34 13. Protocol Timing Defaults 35 14. SLP Protocol Extensions 35 14.1. Required Attribute Missing Option . . . . . . . . . . . . 35 14.2. Cryptographic Algorithm Request Option . . . . . . . . . 36 15. Optional Configuration 36 16. IANA Considerations 38 17. Internationalization Considerations 38 18. Security Considerations 39 19. Acknowledgments 40 20. Full Copyright Statement 40 1. Introduction Traditionally, users find services by using the name of a network host (a human readable text string) which is an alias for a network address. The Service Location Protocol eliminates the need for a user to know the name of a network host supporting a service. Rather, the user names the service and supplies a set of attributes Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 1]
Internet Draft Service Location Protocol 4 May 1998 which describe the service. The Service Location Protocol allows the user to bind this description to the network address of the service. Service Location provides a dynamic configuration mechanism for applications in local area networks. It has been designed to serve enterprise networks with shared services, and it may not necessarily scale for wide-area service discovery throughout the global Internet. Applications are modeled as clients that need to find servers attached to any of the available networks within the 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. The Service Location Protocol (SLP) is presented in two parts. The first are the required features of the protocol. The second are the extended features of the protocol which are optional or allow greater scalability. 2. Terminology User Agent (UA) A process working on the user's behalf to establish contact with a useful service. The UA retrieves service information from the Service Agents or Directory Agents. Service Agent (SA) A process working on the behalf of one or more services to advertise the services. Directory Agent (DA) A process which collects and caches service advertisements from SAs. If there is a DA, UAs use them in preference to SAs. There can only be one DA present per given host. Service Type Each type of service has a unique Service Type string. Naming Authority The agency or group which catalogues given Service Types and Attributes. The default Naming Authority is IANA. Scope A collection or set of services that make up a logical group. URL A Universal Resource Locator - see [9]. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 2]
Internet Draft Service Location Protocol 4 May 1998 SLP v1 The version of Service Location Protocol specified in RFC 2165 [21]. 2.1. Notation Conventions 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 RFC 2119 [10]. Syntax Syntax for string based protocols follow the conventions defined for ABNF [13]. Strings Strings in the protocol are NOT null terminated. They are always proceeded by a two byte length field. String List This construct, used frequently in the protocol, is a comma delimited list of strings with the following syntax: string-list = string / string `,' string-list In format diagrams, any field ending with a \ indicates a variable length field, given by a prior length field in the protocol. 3. Protocol Overview 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. SLP is a request-reply protocol; in a typical operation a User Agent (UA) issues a request for service information and awaits one or more replies containing the requested information. Depending on the environment, replies will be sent to the UA by a SA, a DA, or by both. For smaller environments, SLP allows a simple peer-to-peer deployment consisting only of UAs and SAs. For larger environments, SLP allows the consolidation of service configuration data at one or more DAs. DAs, in addition to consolidating service information, allow information to be organized according to administrative, usage, or type domains using "scopes." SLP Messages are normally transmitted in datagrams using UDP/IP. Requests may be unicast, multicast, or broadcast. When a UA Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 3]
Internet Draft Service Location Protocol 4 May 1998 multicasts or broadcasts a request, it will often receive more than one reply. Replies must be unicast, though errors are NOT returned in this case. In cases where a reply is too large to fit within a datagram, the UA may reissue the request using TCP. Requests which are too large to fit into a datagram are always sent using TCP. Hosts may be configured statically or by using DHCP options 78 and 79 to issue requests to specific SAs or DAs. Otherwise, SLP allows a host to "bootstrap" itself, beginning with no knowledge of any services or SLP agents beyond its own UA. To bootstrap itself, the host must multicast or broadcast its first request. Certain conditions will influence the best strategy for deploying SLP in specific environments. Centralizing service information using DAs simplifies the process by which UAs obtain service information. However, it is not necessary to centralize service-related information in smaller installations; multicast queries are adequate. Specific environments may have special policies regarding broadcasting or multicasting. This document specifies a range of usage models for SLP, beginning with a lightweight and simple minimal implementation for smaller or constrained environments. SLP can be scaled upward from the minimal implementation by deploying more richly featured UAs and SAs, and by adding DAs. A SLP v2 implementation MAY support SLP v1 [21]. 4. URLs used with Service Location A Service URL indicates the location of a service. This URL may be of the service: scheme [14] (reviewed in section 4.1), or any other URL scheme conforming to the URL standard [9], except that URLs without address specifications SHOULD NOT be advertised by SLP. The service type for an arbitrary URL is typically its scheme name. For example, the service type string for "http://www.srvloc.org" is "http". Reserved characters in URLs follow the rules in [9]. 4.1. Service: URLs Service URL syntax and semantics are defined in [14]. Any network service may be encoded in a Service URL. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 4]
Internet Draft Service Location Protocol 4 May 1998 What follows is an introduction to Service URLs and an example showing a simple application of them, representing standard network services. A Service URL may be of the form: "service:"<srvtype>"://"<addrspec> The Service Type of this service: URL is defined to be the string up to (but not including) the final `:' before <addrspec>, the address specification. <addrspec> is a hostname (which should be used if possible) or dotted decimal notation for a hostname, followed by an optional `:' and port number. A service: scheme URL may be formed with any standard protocol name by concatenating "service:" and the reserved port [1] name. For example, "service:tftp://myhost" would indicate a tftp service. An http service on a nonstandard port could be "service:http://webby:8080''. Service Types may be defined by a "service template'' [14], which provides expected attributes, values and protocol behavior. That document also describes 'Abstract Service Types.' An abstract service type has 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. For example: a SrvRqst or AttrRqst which specifies "service:printer" as the Service Type will match the URL service:printer:lpr://hostname and service:printer:http://hostname. If the requests specified "service:printer:http" they would match only the latter URL. An optional substring MAY follow the last `.' character in the service type string is the Naming Authority, as described in Section 9.6. Service types with naming authorities are distinct. In other words, service:x.one and service:x.two are different service types. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 5]
Internet Draft Service Location Protocol 4 May 1998 4.2. URL Entries 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. URL Entries, defined as shown above, are used in Service Replies and Service Registrations. 5. Service Attributes A service advertisement is often accompanied by Service Attributes. These attributes are used by UAs to select services in Service Requests. The attributes which may be used are typically defined by a Service Template [14] for a particular service type. Services which are advertised according to a standard template MUST register all service attributes which the standard template requires. URLs with schemes other than "service:" MAY be registered with attributes. Non-standard attributes names should begin with "x-", because no standard attribute name will ever have those initial characters. An attribute list is a string encoding of the attributes of a service. The following ABNF [13] grammar applies to lists of attributes: attr-list = attribute / attribute `,' attr-list attribute = `(' attr-tag `=' attr-val-list `)' / attr-tag attr-val-list = attr-val / attr-val `,' attr-val-list attr-tag = 1*safe-tag attr-val = intval / strval / boolval / opaque intval = [-]1*DIGIT strval = 1*safe-val boolval = "TRUE" / "FALSE" opaque = "\FF" 1* ( `\' HEXDIGIT HEXDIGIT ) safe-val = ; Any character except reserved. safe-tag = ; Any character except reserved, star and bad-tag. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 6]
Internet Draft Service Location Protocol 4 May 1998 reserved = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' / `~' / CTL escape-val = `\' HEXDIG HEXDIG bad-tag = CR / LF / HT / `_' star =`*' 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 '=' or '!='. 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; see Section 6.3. Opaque Opaque values are sequences of bytes. These are distinguished from Strings since they begin with the sequence "\FF". This, unescaped, is an illegal UTF8 character, 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\00". A string which contains escaped values other than from the reserved set of characters is illegal. If such a string is included in an <attr-list>, <tag-list> or search filter the SA or DA which receives it MUST return a PARSE_ERROR in the reply. A keyword has only an <attr-tag>, and no values. Attributes can have one or multiple values. All values are expressed as strings. All attribute 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 values must be consistent, i.e., x=4,true,sue,\ff\00\00 is disallowed. A DA or SA MUST return an INVALID_REGISTRATION error. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 7]
Internet Draft Service Location Protocol 4 May 1998 6. Required Features Service discovery is performed on behalf of a client by SLP UA functionality. A host's services are represented by a SA which responds to UA requests. A third element in the framework is the DA which is a cache of service information. The UA and SA interaction with a DA is discussed here, but DA implementation is not part of the minimal specification. Wants this information: Client Application - - - - - - - - - - - - -> Service USES USES User Agent -----------------------+--> Service Agent (Request: SrvRqst | ^ | (Request: SrvReg Reply: SrvRply | | | Reply: SrvAck) or DAAdvert) | DAAdvert v +---> Directory Agent The UA issues a SrvRqst using multicast to the assigned address, requesting the service-type `directory-agent' and the scope list it has been configured with. If it receives any results, all subsequent service requests SHOULD unicast to the DA indicated in the URL in the DAAdvert reply. If it does not receive a reply, it multicasts subsequent requests and SAs will respond. It should retry DA discovery once every CONFIG_DA_FIND seconds if it knows of no DAs, if subsequent discovery is required. UAs MUST be prepared for the possibility that the service information they obtain from DAs is stale. The SA also issues a SrvRqst for DAs, as described above. If any DAs are discovered, the SA MUST register all of its services with the DA using a series of SrvReg requests. The SrvAck indicates whether the DA has been successful. SAs listen for multicast messages. If they receive a SrvRqst, they will respond with a SrvRply as defined below. If the SAs receive a DAAdvert (which DAs periodically emit) they must remotely register all services with it which support one or more of the scopes in DA's scope list. Scope strings are used for scalability. UAs, DAs and SAs are assigned scopes to provision services: UAs request scopes in some or all of the scopes which administrators desire they use. SAs advertise services in all of their assigned scopes. DAs use scope to cache only a subset of all services, and respond to requests by a subset of all UAs. A scope is called 'protected' if it is associated with a particular mechanism for authentication (see section 11). Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 8]
Internet Draft Service Location Protocol 4 May 1998 6.1. Use of UDP, TCP, and Multicast The Service Location Protocol uses multicast when supported at the network layer. The reserved port for SLP is 427. This is the destination port for all SLP messages. SLP messages MAY be transmitted on an ephemeral port. The default maximum transmission unit is 1400 bytes. The Administratively Scoped SLP Multicast [17] address is 239.255.255.253. SLP Requests messages are multicast to the Service Location Multicast Address. The default TTL to use for multicast is 32. In isolated networks, broadcasts will work in place of multicast. To that end, SAs SHOULD and DAs MUST listen for broadcast Service Location request messages to port 427. This allows UAs which lack multicast capabilities to still make use of Service Location on isolated networks. Setting multicast TTL to less than 32 (the default) limits the range of SLP discovery in a network, and localizes service information in the network. 6.1.1. UDP and Multicast Transmission of SLP Messages UAs MUST be able to issue requests to DAs using UDP and SAs using multicast/convergence. SAs MUST be able to respond to UDP and multicast requests. If a SLP message does not fit into a UDP datagram it MUST be truncated to fit, and the OVERFLOW flag is set in the reply header. A UA which receives such a truncated reply MAY open a TCP connection 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. 6.2. Use of TCP A SrvReg or SrvDeReg may be too large to fit into a datagram. To send SLP messages which do not fit in a datagram, a TCP connection MUST be established. To avoid the need to implement TCP, one MUST insure that: - UAs never issue requests larger than the Path MTU. SAs can forego TCP support only if unicast requests arriving for its services will never be longer than the path MTU. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 9]
Internet Draft Service Location Protocol 4 May 1998 - UAs can accept replies with the 'OVERFLOW' flag set, and make use of the first result included. - 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. This is possible if the SA is an embedded system, for instance, with a very limited set of service URLs and attributes that it is configured with. A TCP connection initiated by an Agent MAY be used for a single transaction. It may MAY be used for multiple transactions. Since there are length fields in the message headers, the Agents can send multiple requests along a connection and read the return stream for acknowledgments and replies. The initiating agent is responsible for closing the TCP connection. The DA should wait at least CONFIG_CLOSE_CONN seconds before closing an idle connection. DAs and SAs SHOULD eventually close idle TCP connections to ensure robust operation, even when the agent which opened a connection neglects to close it. See Section 13 for timing rules. 6.2.1. Retransmission of multicast messages Requests to SAs are multicast repeatedly (with a recommended wait interval of CONFIG_MC_RETRY) until there are no new responses, or CONFIG_MC_MAX seconds have elapsed. DA discovery requests use different timing for repeated requests, CONFIG_DA_RETRY. Multicast requests SHOULD be reissued over 15 seconds (say 3 times total) until a result has been obtained. SAs MUST register with all discovered DAs. UAs need only wait till they obtain the first reply which matches their request. Unicast requests (SrvReg or SrvRqst) to a DA should be retried until either a response (which might be an error) has been obtained, or for 5 seconds. When SLP SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast, they contain a <PRList> of previous responders. In those cases, 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. Any DA or SA which sees its address in the <PRList> MUST NOT respond to the request. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 10]
Internet Draft Service Location Protocol 4 May 1998 6.3. Strings in SLP messages All strings are encoded using UTF8 [22] and are NOT null terminated when transmitted. The escape character is a backslash (ASCII 0x5c) followed by the two hexadecimal digits of the escaped character. Only reserved characters are escaped. For example, a comma (ASCII 0x29) is escaped as `\29'. String lists used in SLP define the comma to be the delimiter between list elements so commas in data strings must be escaped in this manner. String comparison for order and equality in SLP MUST be case insensitive inside the ASCII subrange of UTF8: It SHOULD be supported throughout the entire Unicode [6] character set. White space (SPACE, CR, LF, TAB) internal to a string value is folded to a single SPACE character for the sake of string comparisons. For example, " Some String " matches "SOME STRING". String comparisons (using comparison operators such as `<=' or `>=') are done using lexical ordering in the character set of the registration, not using any language specific rules. The reserved character `*' may precede, follow or be internal to a string value in order to indicate substring matching. The query including this character matches any character sequence which conforms to the letters which are not wildcarded. 7. Required SLP Messages SLP messages have a binary format and begin with a 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|U|A|F|R| rsvd| Language Tag Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Option Offset | XID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ Language Tag (String using the ASCII subset of UTF8 encoding) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type Abbreviation Function-ID Service Request SrvRqst 1 Service Reply SrvRply 2 Service Registration SrvReg 3 Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 11]
Internet Draft Service Location Protocol 4 May 1998 Service Deregister SrvDeReg 4 Service Acknowledge SrvAck 5 Attribute Request AttrRqst 6 Attribute Reply AttrRply 7 DA Advertisement DAAdvert 8 Service Type Request SrvTypeRqst 9 Service Type Reply SrvTypeRply 10 SA Advertisement SAAdvert 11 SAs and UAs MUST support SrvRqst, SrvRply and DAAdvert. SAs MUST also support SrvReg, SAAdvert and SrvAck. For UAs and SAs, support for other messages are OPTIONAL. - Length is the length of the entire SLP message, header included. - The flags are: OVERFLOW (0x80) is set when a message's length exceeds what can fit into a datagram. URLSIG (0x40) is set by a SA when it registers a signed URL with a DA or a signed URL is passed in a SrvRply to a UA. ATTRSIG (0x20) is set by a SA when signed attributes are registered with a DA. FRESH (0x10) is set on every new SrvReg. REQUEST MCAST (0x08) is set when multicasting or broadcasting requests. Rsvd bits MUST be 0. - Lang Tag Length indicates the length of the Language Tag field. - Next Option Offset is set to 0 unless extension options are used. See Section 9.1 for how to interpret unrecognized options. The first extension begins at 'offset' bytes, from the message's beginning, after the SLP message data. - XID is set to a unique value for each unique request. If the request is retransmitted, the same XID is used. Replies set the XID to the same value as the xid in the request. Only unsolicited DAAdverts are sent with an XID of 0. - Language Tag conforms to [7]. The Language Tag in a reply MUST be the same as the Language Tag in the request. If a flag indicates an authentication block will follow, or an option is specified, and these fields are not included in the message, the receiver MUST respond with a PARSE_ERROR. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 12]
Internet Draft Service Location Protocol 4 May 1998 7.1. Service Request 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> String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of <service-type> | <service-type> String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of <scope-list> | <scope-list> String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of predicate string | Service Request <predicate> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In order for a Service to match a SrvRqst, it must belong to a requested scope, support the requested service type, and match the predicate. If the predicate is present, the language of the request (ignoring the dialect part of the Language Tag) must match the advertised service. At least one scope in the SrvRqst Scope List must match the scope of the SA. <PRList> is the Previous Responder List. This <string-list> contains either fully qualified domain names or dotted decimal notation IP (v4) addresses, and is iteratively multicast to obtain all possible results (see Section 6.2.1). UAs SHOULD implement this discovery algorithm. SAs MUST use this to discover all available DAs in their scope, if they are not already configured with DA addresses by some other means. A SA drops all requests silently which include the SA's address in the <PRList>. Once a Previous Responder list plus the request exceeds the path MTU, multicast convergence stops. This algorithm is not intended to find all instances; it finds 'enough' to provide useful results. The <scope-list> is a <string-list> of configured scope names. SAs and DAs which have been configured with any of the scopes in this list will respond. DAs and SAs MUST reply to unicast requests with a SCOPE_NOT_SUPPORTED error if the <scope-list> is omitted or fails to include a scope they support (see Section 11). The only exceptions to this are describe in Section 11.2. The <service-type> string is discussed in Section 4. Normally, a SrvRqst elicits a SrvRply. There are two exceptions: If the <service-type> is set to "service:directory-agent", DAs respond to the SrvRqst with a DAAdvert (see Section 7.5.) If set to "service:service-agent", SAs respond with a SAAdvert (see Section 7.6.) Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 13]
Internet Draft Service Location Protocol 4 May 1998 The <predicate> is a LDAPv3 search filter [15]. This field may be omitted if services are to be discovered simply by type and scope. Otherwise, services are discovered which satisfy the included search filter. If the filter is present, it is applied to each registered service. If the attribute in the filter has been registered with multiple values, the filter is applied to each value and the result is ORed together, i.e., "(x=3)" matches a registration of (x=1,2,3); "(Y!=0)" matches (y=0,1) since Y can be nonzero. Note the matching is case insensitive. Keywords (i.e., attributes without values) are matched with a "presence" filter, as in "(keyword=*)". An incoming request term MUST have the same type as the attribute in a registration in order to match. Thus, "(x=33)" will not match 'x=true', etc. while "(y=foo)" will match 'y=FOO'. "(|(x=33)(y=foo))" will be satisfied, even though "(x=33)" cannot be satisfied because of the 'or'. Wildcard matching can ONLY be done with the '=' filter. In any other case, a PARSE_ERROR is returned. Request terms which include wildcards are interpreted to be Strings. That is, (x=34*) would match 'x=34foo', but not 'x=3432' since the first value is a String while the second value is an Integer and Strings don't match Integers. Examples of Predicates follow. <t> indicates the service type of the SrvRqst, <s> gives the scope-list and <p> is the predicate string. <t>=service:http <s>=DEFAULT <p>=NONE This is a minimal request string. It matches all http services advertised with the default scope. <t>=service:pop3 <s>=SALES,DEFAULT <p>="(user=wump)" This is a request for all pop3 services available in the SALES or DEFAULT scope which serve mail to the user `wump'. <t>=service:backup <s>=BLDG 32 <p>="(&(q<=3)(speed>=1000))" This returns the backup service which has a queue length less than 3 and a speed greater than 1000. It will return this only for services registered with the BLDG 32 scope. DAs are discovered by sending a SrvRqst with the service type set to "service:directory-agent" and the predicate omitted. The scope list SHOULD be set to the configured scope list of the service. (OPTIONALLY the scope list may be omitted, see Section 11.2.) For example: Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 14]
Internet Draft Service Location Protocol 4 May 1998 <t>=service:directory-agent <s>=DEFAULT <p>=NONE This returns DAAdverts for all DAs in the DEFAULT scope. 7.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 a list of URL entries (see Section 4.2) which satisfy a SrvRqst. 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). One authentication block is returned for each protected scope the service was registered in which was present in the <scope-list> of the SrvRqst. 7.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> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of service type string | <service-type> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of <scope-list> | <scope-list> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of attr-list string | <attr-list> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |# of AttrAuths |(if present) Attribute Authentication Blocks...\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The <entry> is a URL Entry as defined in section 4.2. The Lifetime defines how long a DA can maintain the registration. SAs SHOULD reregister with DAs before this lifetime expires (but no more often Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 15]
Internet Draft Service Location Protocol 4 May 1998 than once every CONFIG_REG_SPEED seconds). The Lifetime can be set to the 0xffff (maximum, around 18 hours) and simply reregistered in response to a DAAdvert. This has the disadvantage that if the SA or the service fails, the stale registration will be cached longer. The <service-type> defines the service type of the URL to be registered. This field is authoritative over the URL for the purposes of registration: It MAY differ from the service type of the URL registered. The <scope-list> MUST be set to the configured Scope list of the SA. The default value is "DEFAULT'' (see Section 11). The <attr-list>, if present, specifies the attributes and values to be associated with the URL by the DA (see Section 5). If the registration occurs in a protected scope, the ATTRSIG flag is set in the header, and an Attr Authentication block (see Section 9.2) is transmitted for each protected scope the service is registered in. This is calculated over <ATTRS LENGTH, ATTRS, TIMESTAMP, LENGTH OF SCOPE STRING, SCOPE STRING>. Note that signatures are case and order sensitive. DSA Authentication blocks MUST be included, if any are, though others may be sent in addition. The FRESH flag is set in the SrvReg header unless the 'Update' optimization is being used (see Section 9.5). The registration with the FRESH flag set will replace *entirely* any previous registration for the same URL in the same language. 7.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 = 4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A DA returns a SrvAck to an SA after a SrvReg. It carries only a two byte Error Code (see Section 8). Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 16]
Internet Draft Service Location Protocol 4 May 1998 7.5. Directory Agent Advertisement 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DA Stateless boot Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of URL | URL \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of <scope-list> | <scope-list> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ authentication block (if any) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DAs respond only to SrvRqsts with the MCAST RQST flag set with DAAdverts. The scope list of the SrvRqst must either be omitted or include a scope which the DA supports. Error codes are never returned. The DA Stateless boot Timestamp indicates the state of the DA (see 12.2.2). 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 DAAdvert MAY contain a URL authenticator, which will be generated using a DA Advertising private key. This authenticator is calculated over the following fields: <DA STATELESS BOOT TIMESTAMP, LENGTH OF URL, URL, LENGTH OF SCOPE LIST, SCOPE LIST, AUTHENTICATOR TIMESTAMP>. The protected scope field of the authentication block is omitted in a DAAdvert. The Authenticator Timestamp is set to the time when the DAAdvert expires (may no longer be cached). Note that signatures are case and order sensitive. UAs SHOULD be configured with DA Advertisement public keys so they can verify the authenticity of DAAdverts. If the UA can verify DAAdverts, and the DAAdvert fails to be verified, the UA MUST discard it. 7.6. Service Agent Advertisement UAs MUST NOT solicit SA Advertisements if they have been configured to use a particular DA, if they have been configured with a scope list or if DAs have been discovered. UAs solicit SA Advertisements only when they are explicitly configured to use User Selectable scopes (see Section 11.2) in order to discover the scopes that SAs support. This allows UAs without scope configuration to make Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 17]
Internet Draft Service Location Protocol 4 May 1998 use of either DAs or SAs without any functional difference except performance. 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> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # auth blocks | authentication block (if any) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The SA responds only to multicast SA discovery requests which either include no scope list or a scope which they are configured to use. Error codes are never returned. The URL is "service:service-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 SAAdvert contains a URL authenticator, one for each protected scope the SA supports. If the UA can verify the protected scope SAAdvert, and the SAAdvert fails to be verified, the UA MUST discard it. 8. Errors 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. Errors are only returned for unicast requests. Requests which are multicast are dropped if they result in an error. LANGUAGE_NOT_SUPPORTED = 1: There is data for the service type in the scope in the AttrRqst or SrvRqst, but not in the requested language. PARSE_ERROR = 2: The message fails to obey SLP syntax. INVALID_REGISTRATION = 3: The SrvReg has problems i.e., a 0 lifetime, an omitted language tag, etc. SCOPE_NOT_SUPPORTED = 4: The SLP message did not include a scope in its scope list the SA or DA was configured to use. AUTHENTICATION_ABSENT = 6: The DA expects URL and ATTR authentication in the SrvReg and did not receive it. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 18]
Internet Draft Service Location Protocol 4 May 1998 AUTHENTICATION_FAILED = 7: The DA determines the URL or ATTR signature in the SrvReg came out bad VER_NOT_SUPPORTED = 9: Ver was set to an unsupported 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 Option from the Mandatory range which is not understood. INVALID_UPDATE = 13: The DA received a SrvReg without FRESH set, for an unregistered service. See Section 9.5. RQST_NOT_SUPPORTED = 14: The SA received an AttrRqst or SrvTypeRqst and does not support it. 9. Optional Features The features described in this section are not mandatory. They are useful for interactive use of SLP (where a user rather than a program will select services, using a browsing interface for example) and for scalability of SLP to larger networks. 9.1. Service Location Protocol Extension Options A service location extension option must be specified by a standards track document. The option may be defined to accompany any or all Service Location Messages. A conforming SLP implementation MUST be able to ignore Service Location Extension Options it does not recognize. The format of a Service Location Extension Option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Extension ID | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ Extension Contents \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Option Extension ID is defined by a IETF Standards document which also defines the contents of the extension. The offset to next option is 0 if there is no option following or is set to the length of the current Extension contents. The length of the 'last option' is determined implicitly by summing the length parsed and comparing it to the total length of the message given in the SLP header. Options Extension IDs are assigned in the following way: Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 19]
Internet Draft Service Location Protocol 4 May 1998 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 NOT Standardized, for private use. Optional to implement. Ignore if unrecognized. 0x9000-0xFFFF Reserved: Do not use. Options defined in this document are in Section 14. 9.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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protected Scope String Length | Protected Scope String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ Structured Authentication Block ... \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authentication blocks are returned with certain SLP data to verify that the contents have not been modified. The Block Structure Descriptor (BSD) identifies the format of the Authenticator which follows. BSDs 0x0000-0x7FFF will be identified by IANA. BSDs 0x8000-0x8FFF are for private use. The Timestamp is the time that the service reply expires (to prevent replay attacks.) The Timestamp is a 32-bit unsigned fixed-point number of seconds relative to 0h on 1 January 1900, in SNTP format [18]. SLP agents MUST implement DSA [19] (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. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 20]
Internet Draft Service Location Protocol 4 May 1998 9.2.1. MD5 with RSA in Authentication Blocks BSD=0x0001 indicates that md5withRSAEncryption is selected as the authentication algorithm for the Structured Authentication Block. The Authentication Block will start with the ASN.1 Distinguished Encoding (DER) [11] for "md5WithRSAEncryption", which has the as its value the bytes (MSB first in hex): "30 0d 06 09 2a 86 48 86 f7 0d 01 01 04 05 00" This is then immediately followed by an ASN.1 Distinguished Encoding (as a "Bitstring") of the RSA encryption (using the protected scope's private key) of a bitstring consisting of the OID for "MD5" concatenated by the MD5 [20] message digest computed over the fields above. The exact construction of the MD5 OID and digest can be found in RFC 1423 [8]. 9.2.2. DSA with SHA-1 in Authentication Blocks BSD=0x0002 is defined to be DSA with SHA-1. The signature calculation is defined by [19]. 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) 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. This is followed by a certificate path, as defined by X.509 [12], [2], [3], [4], [5]. 9.2.3. Keyed HMAC with MD5 in Authentication Blocks BSD=0x0003 is defined to be HMAC [16] using keyed-MD5 [20]. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 21]
Internet Draft Service Location Protocol 4 May 1998 Given a secret key K and the data to authenticate, the Authentication Block is computed as follows: 1. opad := 0x36363636363636363636363636363636 (128 bits) 2. ipad := 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C (128 bits) 3. zero_extended_key := K extended by zeroes to be 128 bits long 4. opadded_key := zero_extended_key XOR opad 5. ipadded_key := zero_extended_key XOR ipad 6. HMAC_result := MD5 (opadded_key , MD5 (ipadded_key, data)) The authenticator is the 128-bit value HMAC_result. Note that this authentication scheme works for peer-to-peer implementations (where hosts can both verify and generate authenticators) but not for client-server applications where clients are NOT trusted to create authenticators for services of a protected scope. In this case, Public Key cryptography is used. 9.3. Authentication of a SrvRply Each SA MUST sign the SrvRply if it is responding to a SrvRqst made to a protected scope, adding an Authentication Block containing the signature. The authentication data MUST be calculated over the following data: <LENGTH OF URL, URL, TIMESTAMP, LENGTH OF SCOPE STRING, SCOPE STRING>. The BSD auth bytes are calculated according to the algorithm indicated by the BSD value. Note that signatures are case sensitive, so implementations must transmit URLs in the same case as used to calculate the signature. 9.4. Optimizations with XIDs UAs which retransmit a request use the same XID. This allows a DA or SA to cache its reply to the original request and then send it again, should a duplicate request arrive. This cached information should only be held very briefly. XIDs SHOULD be randomly chosen to avoid duplicate XIDs in requests if UAs restart frequently. 9.5. Service Registration Updates Registrations of a previously registered service are considered an update. Partial updates of service registration are useful when only a single attribute has changed, for instance. In an update, the FRESH flag in the SrvReg header is NOT set. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 22]
Internet Draft Service Location Protocol 4 May 1998 The new registration's attributes replace the previous registration's, but do not affect attributes which were included previously and are not present in the update. For example, suppose service:x://a.org has been registered with attributes A=1, B=2, C=3. If a new registration comes for service:x://a.org with attributes C=30, D=40, then the attributes for the service after the update are A=1, B=2, C=30, D=40. Updates MUST NOT be performed for services registered in protected scopes. These must be registered with ALL attributes, with the "FRESH" flag in the SrvReg header set. DAs which receive such update messages return an AUTHENTICATION_FAILED error. If an update is sent and the DA does not have a prior registration for the service, the update fails and the DA responds with a INVALID_UPDATE error. If the update includes a scope list other than the one in the prior registration, the DA returns a SCOPE_NOT_SUPPORTED error. In order to change the scope of a service advertisement it must be deregistered first and reregistered in a new scope. 9.6. Naming Authorities A Naming Authority MAY optionally be included as part of the Service Type string, see Section 4.1. The Naming Authority of a service defines the meaning of the Service Types and attributes registered with and provided by Service Location. The Naming Authority itself is typically a string which uniquely identifies an organization. IANA is the implied Naming Authority when no string is appended. "IANA" itself MUST NOT BE included explicitly. Naming Authorities may define Service Types which are experimental, proprietary or for private use. Using a Naming Authority, one may either simply ignore attributes upon registration or create a local-use only set of attributes for one's site. The procedure to use is to create a 'unique' Naming Authority string and then specify the Standard Attribute Definitions as described above. This Naming Authority will accompany registration and queries, as described in Sections 7.1 and 7.3. Service Types SHOULD be registered with IANA to allow for Internet-wide interoperability. 9.7. Tag Lists Tag lists are used in SrvDeReg and AttrReq messages. The syntax of a <tag-list> item is: Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 23]
Internet Draft Service Location Protocol 4 May 1998 tag-filter = simple-tag / substring simple-tag = 1*filt-char substring = [initial] any [final] initial = 1*filt-char any = `*' *(filt-char `*') final = 1*filt-char filt-char = Any character excluding <reserved> and <bad-tag> (see grammar in Section 5). Wild card characters in a <tag-list> item match arbitrary sequences of characters. For instance "*bob*" matches "some bob I know", "bigbob", "bobby" and "bob". 10. Optional SLP Messages The additional requests provided for SLP provide features for user interaction and for efficient updating of service advertisements with dynamic attributes. 10.1. Service Type Request The Service Type Request (SrvTypeRqst) allows a UA to discover all types of service on a network. This is useful for general purpose service browsers. 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> String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of naming authority | <Naming Authority String> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of <scope-list> | <scope-list> String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The <PRList> list and <scope-list> are interpreted as in Section 7.1. 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 Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 24]
Internet Draft Service Location Protocol 4 May 1998 omitted and ALL Service Types are returned, regardless of Naming Authority. 10.2. Service Type 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 = SrvTypeRply = 10) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code |length of SrvType <string-list>| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SrvType <string-list> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Service Type Strings (as described in Section 4.1) are provided in <string-list>. If the service type has a Naming Authority other than IANA it MUST be returned following the service type string and a `.' character. Service types with the IANA Naming Authority do not include a Naming Authority string. 10.3. Attribute Request The Attribute Request (AttrRqst) allows a UA to discover attributes of a given service (by supplying its URL) or for an entire service type. The latter feature allows the UA to construct a query for an available service by selecting desired features. The UA may request that all attributes are returned, or only a subset of them. 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> string \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of <tag-list> string | <tag-list> string \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The <PRList> and <scope-list> are interpreted as in Section 7.1. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 25]
Internet Draft Service Location Protocol 4 May 1998 The URL field can take two forms. It can simply be a Service Type (see Section 4.1), such as "http" or "service:tftp". In this case, all attributes and the full range of values for each attribute of all services of the given Service Type is returned. The URL field may alternatively be a full URL, such as "service:printer:lpr://igore.wco.ftp.com:515/draft" or "nfs://max.net/znoo". In this, only the attributes for the service of the specified URL is defined are returned. The <tag-list> field is a string list of attribute tags, as defined in Section 9.7 which indicates the attributes to return in the AttrRply. If <tag-list> is omitted, all attributes are returned. <tag-list> MUST be omitted and a full URL MUST be included when attributes are requested in a protected scope from a DA, otherwise the DA will reply with an AUTHENTICATION_FAILED error. 10.4. 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> string | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ <attr-list> \ # Auth Blocks | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ (if present) Attribute Authentication Blocks... \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the <attr-list> and the Attr Authentication Block is identical to that used for SrvReg, see Section 9.2. Attribute replies SHOULD be returned with the original case of the string registration intact, as they are likely to be human readable. In the case where the AttrRqst was by service type, all attributes defined for the service type, and all their values are returned. Only one copy of each attribute tag or String value should be returned, arbitrarily choosing one version (with respect to upper and lower case): Duplicate attributes and values SHOULD be removed. Note that the <attr-list> returned from a DA in a protected scope MUST be identical to the <attr-list> registered by a SA, in order for the Attr Authenticator to be successful. One attribute authentication block is returned for each scope in the <scope-list> which is a protected scope. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 26]
Internet Draft Service Location Protocol 4 May 1998 10.5. Attribute Request/Reply Examples Suppose that printer services have been registered as follows: Registered Service: URL = service:printer:lpr://igore.wco.ftp.com/draft scope-list = Development Lang. Tag = en Attributes = (Name=Igore),(Description=For developers only), (Protocol=LPR),(location-description=12th floor), (Operator=James Dornan \3cdornan@monster\3e), (media-size=na-letter),(resolution=res-600),x-OK URL = service:printer:lpr://igore.wco.ftp.com/draft scope-list = Entwicklung Lang. Tag = de Attributes = (Name=Igore),(Beschreibung=Nur fuer Entwickler), (Protocol=LPR),(Standort-beschreibung=13te Etage), (Techniker=James Dornan \3cdornan@monster\3e), (Format=na-letter),(Resolution=res-600),x-OK URL = service:printer:http://not.wco.ftp.com/cgi-bin/pub-prn scope-list = Development Lang. Tag = en Attributes = (Name=Not),(Description=Experimental IPP printer), (Protocol=http),(location-description=QA bench), (media-size=na-letter),(resolution=other),x-BUSY Notice the first printer, "Igore" is registered in both English and German. The `<' and `>' characters in the Operator attribute value which are part of the Email address had to be escaped, as they are reserved characters for values. The string "PROTOCOL" is 'literal' so it is not translated to different languages, see [14]. The attribute Request: URL = service:printer:lpr://igore.wco.ftp.com/draft scope-list = Entwicklung Lang. Tag = de tag-list = Resolution,St* receives the Attribute Reply: (Standort-beschreibung=13te Etage),(Resolution=res-600) The attribute Request: Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 27]
Internet Draft Service Location Protocol 4 May 1998 URL = service:printer scope-list = Development Lang. Tag = en tag-list = x-*,resolution,protocols receives an Attribute Reply containing: (protocols=http,LPR),(resolution=res-600,other),x-OK,x-BUSY The first request is by service instance and returns the requested values, in German. The second request is by abstract service type (see Section 4) and returns values from both "Igore" and "Not". 10.6. Service Deregistration A service which is registered will time out at the DA 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 = 5) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of Scope <string-list> | Scope <string-list> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | URL Entry | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of <tag-list> string | <tag-list> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The scope list is a <string-list> of scopes. The SA MUST retry if there is no response from the DA, see Section 12.3. The DA acknowledges a SrvDeReg with a SrvAck. Once the SA receives an acknowledgment indicating success, it can assume that the service is 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. If the URL deregistered has not been registered with the DA in the scope specified in the SrvDeReg message, an INVALID_REGISTRATION error is returned. The lifetime in the URLEntry field is ignored for the purposes of the SrvDeReg. The <tag-list> is a <string-list> of attribute tags to deregister as defined in Section 9.7. If no <tag-list> is present, the SrvDeReg deregisters the service in all languages it has been Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 28]
Internet Draft Service Location Protocol 4 May 1998 registered in. If the <tag-list> is present, the SrvDeReg deregisters the attributes whose tags are listed in the tag spec. Services registered in protected scopes MUST NOT include a <tag-list> in a SrvDeReg message: A DA will respond with an AUTHENTICATION_FAILED error in this case. If the service to be deregistered was registered in a protected scope, a URL authentication block for that protected scope must be included. Otherwise, the DA returns an AUTHENTICATION_ABSENT error is returned. If the message fails to be verified by the DA, an AUTHENTICATION_FAILED error is returned by the DA. 11. Scopes Scopes are sets of services. 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. A client seeking services is configured to use one or more scopes. The user will only discover those services which have been configured for him or her to use. By configuring UAs and SAs with scopes, administrators may provision services. Scopes are the primary means an administrator has to scale SLP deployments to larger networks. When DAs with NON-DEFAULT scopes are present on the network, further gains can be had by configuring UAs and SAs to have a predefined non-default scope. These agents can then perform DA discovery and make requests using their scope. This will limit the number of replies. Scopes strings are case insensitive. The default SCOPE string is "DEFAULT". 11.1. Scope Rules SLP messages which fail to contain the 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). Every AttrRqst, SrvTypeRqst, DAAdvert, SAAdvert, SrvReg and SrvRqst (except for DA and SA discovery requests) message MUST include a scope list. A UA MUST unicast its SLP messages to a DA which supports the desired scope, in preference to multicasting a request to SAs. A UA MAY multicast the request if no DA is available in the scope it is configured to use. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 29]
Internet Draft Service Location Protocol 4 May 1998 11.2. Administrative and User Configurable Scopes All requests and services are scoped. The two exceptions are SrvRqsts for "service:directory-agent" and "service:service-agent". These MAY exclude a scope list in the request but are only used to support the 'USER SELECTABLE SCOPE' model. There are two possible ways to configure SAs and UAs with scope strings: DEFAULT The scope "DEFAULT" is used. ADMINISTRATIVE UAs and SAs are configured with lists of scopes to use by system administrators. If this is the case, UA requests will specify some or all of these scopes and services registered by SAs will specify all of these scopes. The user MUST NOT be presented with other scopes than the preconfigured ones. Administrative scoping allows services to be provisioned, so that users will only see services they are intended to see. Additionally, it is possible to explicitely configure UAs with no scope list at all. In this case UAs obtain their scope list from DAAdverts (or if DAs are not available, from SAAdverts.) This allows the user to select his or her own scope. User configurable scopes allow a user to discover any service, but require them to do their own selection of scope. This is similar to the way AppleTalk and LanManager networking allow user selection of AppleTalk Zone or Windows Workgroups. Note that the two configuration choices are not compatible. One model allows administrators control over service provision. The other delegates this to users (who may not be prepared to do any configuration of their system). 11.3. Protected Scopes A protected scope is identical to a non protected scope except that it allows authentication of service information. If a `protected scope' is configured, it must be accompanied by a key so that authentication calculation is possible. For example, a shared secret could be installed for each host using a protected scope. It is far wiser to use public key cryptography. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 30]
Internet Draft Service Location Protocol 4 May 1998 In protected scopes, only a subset of SLP functionality is possible: AttrRqst and SrvDeReg messages MUST NOT contain a <tag-list>. DAs MUST verify SrvReg and SrvDeReg messages sent by SAs which select protected scopes. UAs MUST verify SrvRply and AttrRply messages sent using protected scopes before returning them to client processes. 12. Directory Agents DAs cache service location and attribute information. They exist to enhance the performance and upward scalability of SLP. Multiple DAs may provide further scalability and robustness of operation. The DAs can store replicated service information which remains available even when one of the DAs fails. For use in networks with multiple subnets, a DA can be used to provide a central clearing house of information for UAs. The DA address can be dynamically configured with Agents using DHCP, or determined by static configuration. Passive detection of DAs by SAs enables services to be advertised consistently among DAs of the same scope. Invalid advertisements age out, leaving only transient stale registrations in DAs, even in the case of a failure of a SA. 12.1. Directory Agent Rules When DAs are present, each SA MUST register all its service with DAs that support one or more of its scope(s). Furthermore, UAs SHOULD unicast requests directly to a DA (when scoping rules allow), hence avoiding using the multicast and convergence algorithm, to obtain service information. This decreases network utilization and increases the speed at which UAs can obtain service information. A single DA can support many UAs. Moreover, many DAs can reside together on a network, enabling load balancing and redundancy. DAs reduce the load on SAs, making simpler implementations of SAs possible. UAs send the same requests to DAs that they would send to SAs and expect the same results. DAs MUST flush service advertisements once their lifetime expires or their URL Authentication Block "Timestamp" of expiration is past. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 31]
Internet Draft Service Location Protocol 4 May 1998 DAAdverts MUST include DA Stateless boot Timestamp, in the same format as the Authentication Block, see Section 9.2. If the DA comes up stateless, this is the current time. If the DA keeps service advertisements between boots, this timestamp indicates the last stateless reboot. This timestamp is set to 0 in a DAAdvert to notify UAs and SAs that the DA is going down. DAs which receive a multicast SrvRqst for the service type "service:directory-agent" MUST silently discard it if the <scope-list> is (a) not omitted and (b) does not include a scope they are configured to use. Otherwise the DA MUST respond with a DAAdvert. DAs MUST send an initial and periodic unsolicited DAAdvert messages. DAs MUST respond to AttrRqst and SrvTypeRqst messages (these are OPTIONAL only for SAs, not DAs.) 12.2. Directory Agent Discovery UAs can discover DAs using static configuration, DHCP options 78 and 79, or by multicasting (or broadcasting) Service Requests using the convergence algorithm in Section 6.2.1. See Section 6 which describes unsolicited DAAdverts and how SAs respond to them. Section 12.2.2 includes an optimization which SAs may use to minimize the number of times they must reregister with DAs. SAs MUST listen for DAAdverts, passively, as described in Section 7.5. UAs SHOULD do this. DAs MUST send unsolicited DAAdverts once per CONFIG_DA_BEAT. An unsolicited DAAdvert has an XID of 0. A URL with the Service Type "service:directory-agent" is synthesized to indicate the DA's location as defined in Section 7.5. For example: "service:directory-agent://foobawooba.org". The following sections describe suggested timing algorithms which allow SLP to scale to larger deployments. 12.2.1. Active DA Discovery After a UA or SA restarts, their initial DA discovery request SHOULD be delayed for some random time uniformly distributed from 0 to CONFIG_START_WAIT seconds. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 32]
Internet Draft Service Location Protocol 4 May 1998 The UA or SA sends the DA Discovery request using a SrvRqst, as described in Section 7.1. DA Discovery requests MUST include previous responders in a Previous Responder List. SAs which discover DAs actively MUST wait a random time between 0 and CONFIG_REG_ACTIVE seconds before registering their services. 12.2.2. Passive DA Advertising 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. 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 before beginning DA registration: CONFIG_REG_PASSIVE. 12.3. Reliable Unicast to DAs If a DA fails to respond to a unicast UDP message in CONFIG_DA_RETRY seconds, the message should be retried. If a DA fails to respond after CONFIG_DA_MAX seconds, the SA should consider the DA to have gone down. The UA should use a different DA. If no such DA responds, DA discovery should be used to find a new DA. Care should be taken not to do Active DA Discovery more than once per CONFIG_DA_FIND seconds. If no DA is available, multicast is used. 12.4. DA Scope Configuration DAs are configured with the "DEFAULT" scope, by default. Administrators may add other configured scopes, in order to support UAs and SAs in non default scopes. The default configuration SHOULD NOT be removed from the DA unless: - There are other DAs which support the "DEFAULT" scope, or - All UAs and SAs have been configured with non-default scopes. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 33]
Internet Draft Service Location Protocol 4 May 1998 Non-default scopes should be phased-in as the SLP deployment grows. Default scopes should be phased out only when the non-default scopes are well deployed. If a DA and SA are coresident on a host (quite possibly implemented by the same process), configuration of the host is considerably simplified if the SA supports only scopes also supported by the DA. That is, the SA SHOULD NOT advertise services in any scopes which are not supported by the coresident DA. This means that incoming requests can be answered by a single data store; the SA and DA registrations do not need to be kept separately. 12.5. DAs and Authentication Blocks DAs are not configured with protected scope private keys. This means they will not be able to sign URLs and Attribute lists, but only cache them for SAs, forwarding them to UAs. Consequently, in a protected scope the DA will not accept: SrvReg without the FRESH flag set or AttrRqst or SrvDeReg with a <tag-list> included. In these cases an AUTHENTICATION_FAILED error is returned. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 34]
Internet Draft Service Location Protocol 4 May 1998 13. Protocol Timing Defaults Interval name Section Default Value Meaning ------------------- ------- ------------- ------------------------ CONFIG_MC_RETRY 6.2.1 each second, Retry multicast query backing off until no new values gradually arrive. CONFIG_MC_MAX 6.2.1 15 seconds Max time to wait for a complete multicast query response (all values.) CONFIG_START_WAIT 12.2.1 3 seconds Wait to perform DA discovery on reboot. CONFIG_DA_RETRY 12.3 2 seconds Retransmit DA discovery, try it 3 times. CONFIG_DA_MAX 12.3 6 seconds Give up on requests sent to a DA. CONFIG_DA_BEAT 12.2.2 3 hours DA Heartbeat, so that SAs passively detect new DAs. CONFIG_DA_FIND 12.3 900 seconds Minimum interval to wait before repeating Active DA discovery. CONFIG_REG_PASSIVE 12.2 1-3 seconds Wait to register services on passive DA discovery. CONFIG_REG_ACTIVE 7.3 1-3 seconds Wait to register services on active DA discovery. CONFIG_CLOSE_CONN 6.2 5 minutes DAs and SAs close idle connections. 14. SLP Protocol Extensions 14.1. Required Attribute Missing Option 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 Type = 0x0001 | Extension Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template IDVer Length | Template IDVer String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Required Attr <tag-list> Length| Required Attr <tag-list> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Required attributes and the format of the IDVer string are defined by [14]. If a SA or DA receives a SrvRqst or a SrvReg which fails to include an attribute which is required for the requested Service Type, it Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 35]
Internet Draft Service Location Protocol 4 May 1998 returns the Required Attribute Extension in addition to the reply corresponding to the message. The sender SHOULD reissue the message with a search filter including the attributes listed in the returned Required Attribute Extension. Similarly, the Required Attribute Extension may be returned in response to a SrvDereg message that contains a required attribute tag. The Template IDVer String is the name and version number string of the service template which defines the given attribute as required. It SHOULD be included, but can be omitted if a given SA or DA has been individually configured to have 'required attributes.' The Required Attribute <tag-list> may not include wild cards. 14.2. Cryptographic Algorithm Request Option If a UA wishes to obtain an Authentication Block using a non-default algorithm (i.e., not using DSA), it includes a SLP Extension option requesting a particular BSD. 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 Type = 0x0002 | Extension Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Desired BSD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Extension Contents are a two byte value representing the desired BSD, see Section 9.1. If the DA or SA does not support this OPTIONAL extension, it will ignore it and return a DSA authentication block. If it does support the Extension, but not the algorithm identified by the BSD, it will return an AUTHENTICATION_ALGO_UNKNOWN error. If it supports the extension and the algorithm identified by BSD it will return an authentication block using the desired algorithm. 15. Optional Configuration BROADCAST ONLY An SLP Agent SHOULD be configurable to use broadcast only. See Sections 6.1 and 12.2. 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 Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 36]
Internet Draft Service Location Protocol 4 May 1998 predefined and DHCP-configured DAs and perform no active or passive DA discovery. MULTICAST TTL The default multicast TTL is 32. Agents SHOULD be configurable to other values. A lower value will focus the multicast convergence algorithm on smaller subnetworks, decreasing the number of responses and increases the performance of service location. This may result in UAs obtaining different results for the identical requests depending on where they are connected to the network. ENHANCED TIMING Non default time values MAY be configurable. See Section 13. SCOPES A UA MAY be configurable to support User Selectable scopes by omitting all predefined scopes. See Section 11.2. A UA or SA MUST be configurable to use specific scopes by default. Additionally, a UA or SA MUST be configurable to use specific scopes for requests for and registrations of specific service types. DA SCOPE The scope or scopes of a DA MUST be configurable. The default value for a DA is to have the scope "DEFAULT" if not otherwise configured. DHCP Configuration DHCP options 78 and 79 may be used to configure SLP. If DA locations are configured using DHCP, these SHOULD be used in preference to DAs discovered actively or passively. One or more of the scopes configured using DHCP MUST be used in requests. The entire configured scope list MUST be used in registration and DA configuration messages. SERVICE TEMPLATE UAs and SAs MAY be configured with Service Templates. Besides simplifying the specification of attribute values, this also allows them to enforce the inclusion of 'required' attributes in SrvRqst, SrvReg and SrvDeReg messages. DAs MAY be configured with templates to allow them to WARN UAs and SAs in these cases. See Section 10.4. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 37]
Internet Draft Service Location Protocol 4 May 1998 ADMINISTRATIVE SCOPED MULTICAST ADDRESS If an Administrative Multicast Scope Discovery Protocol is used, this protocol SHOULD be used to discover and the enclosing Administratively Scoped multicast [17] address ranges. The address to for SLP is always '2' down from the top of the from the 'relative administrative scoped multicast address assignment range' in any scope. By default the address to use is "239.255.255.253". 16. IANA Considerations Further Block Structured Descriptor (BSD) values 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. The IANA will assign BSD numbers (from the range 0x0003 to 0x7FFF) on a first come, first served basis. 17. Internationalization Considerations SLP messages support the use of multiple languages by providing a Language Tag field in the common message header (see Section 7). Services MAY be registered in multiple languages. This provides attributes so that users with different language skills may select services interactively. A service which is registered in multiple languages may be queried in multiple languages. The language of the SrvRqst or AttrRqst is used 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 [14] 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 Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 38]
Internet Draft Service Location Protocol 4 May 1998 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. 18. Security Considerations SLP provides for authentication of service URLs and service attributes. This provides UAs and DAs with knowledge of the integrity of service URLs and attributes included in SLP messages. The only systems which can generate digital signatures are those which have been configured by administrators in advance. Agents which verify signed data may assume it is 'trustworthy' in as much as administrators have ensured the cryptographic keying of SAs and DAs reflects 'trustworthiness.' Service Location does not provide confidentiality. Because the objective of this protocol is to advertise services to a community of users, confidentiality might not generally be needed when this protocol is used in non-sensitive environments. Specialized schemes might be able to provide confidentiality, if needed in the future. Sites requiring confidentiality should implement the IP Encapsulating Security Payload (ESP) [3] to provide confidentiality for Service Location messages. Using unprotected scopes, an adversary might easily use this protocol to advertise services on servers controlled by the adversary and thereby gain access to users' private information. Further, an adversary using this protocol will find it much easier to engage in selective denial of service attacks. Sites that are in potentially hostile environments (e.g., are directly connected to the Internet) should consider the advantages of distributing keys associated with protected scopes prior to deploying the sensitive directory agents or service agents. Service Location 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. Service Location will make use of the mechanisms provided by the Security Area of the IETF for key distribution as they become available. At this point it would only be possible to gain the benefits associated with the use of protected Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 39]
Internet Draft Service Location Protocol 4 May 1998 scopes if some cryptographic information can be preconfigured with the end systems before they use Service Location. 19. Acknowledgments This document incorporates ideas from work on several discovery protocols, including RDP by Perkins and Harjono, and PDS by Michael Day. 20. Full Copyright Statement Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or 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." References [1] Port numbers, July 1997. ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers. [2] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment DAM 4 to ISO/IEC 9594-2, December 1996. Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 40]
Internet Draft Service Location Protocol 4 May 1998 [3] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment DAM 2 to ISO/IEC 9594-6, December 1996. [4] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment DAM 1 to ISO/IEC 9594-7, December 1996. [5] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment DAM 1 to ISO/IEC 9594-8, December 1996. [6] Unicode Technical Report #4. The unicode standard, version 2.0. Technical Report ISBN 0-201-48345-9, The Unicode Consortium, 1996. [7] H. Alvestrand. Tags for the Identification of Languages. RFC 1766, March 1995. [8] D. Balenson. Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers. RFC 1423, February 1993. [9] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource Locators (URL). RFC 1738, December 1994. [10] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, March 1997. [11] CCITT. Specification of the Abstract Syntax Notation One (ASN.1). Recommendation X.208, 1988. [12] CCITT. The Directory Authentication Framework. Recommendation X.509, 1988. [13] D. Crocker and P. Overell. Augmented BNF for Syntax Specifications: ABNF. RFC 2234, November 1997. [14] E. Guttman, C. Perkins, and J. Kempf. Service Templates and service: Schemes. draft-ietf-svrloc-service-scheme-05.txt, November 1997. (work in progress). [15] T. Howes. The string representation of LDAP search filters. draft-ietf-asid-ldapv3-filter-03.txt, October 1997. (work in progress). [16] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing for Message Authentication. RFC 2104, February 1997. [17] David Meyer. Administratively Scoped IP Multicast. draft-ietf-mboned-admin-ip-space-04.txt, November 1997. (work in progress). Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 41]
Internet Draft Service Location Protocol 4 May 1998 [18] D. Mills. Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. RFC 2030, October 1996. [19] National Institute of Standards and Technology. Digital signature standard. Technical Report NIST FIPS PUB 186, U.S. Department of Commerce, May 1994. [20] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, April 1992. [21] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service Location Protocol. RFC 2165, July 1997. [22] F. Yergeau. UTF-8, a transformation format of ISO 10646. RFC 2279, January 1998. Authors' Addresses Erik Guttman Charles Perkins Sun Microsystems Sun Microsystems Bahnstr. 2 901 San Antonio Road 74915 Waibstadt Palo Alto, CA 94040 Germany USA Phone: +49 7263 911701 +1 650 786 6464 Fax: +1 650 786 6445 Email: Erik.Guttman@sun.com cperkins@sun.com John Veizades Michael Day @Home Network Intel 385 Ravendale Dr. 734 E. Utah Valley Dr., Ste. 300 Mountain View, CA 94043 American Fork, Utah, 84003 USA USA Phone: +1 650 569 5243 +1 801 763 2341 Fax: +1 801 756 8349 Email: veizades@home.net Michael_Day@ccm.ut.intel.com Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 42]