Internet Engineering Task Force Michael Day INTERNET DRAFT IBM 07 January 2003 Expires in six months Exclusion Extension for Service Location Protocol v2 draft-day-svrloc-exclusion-03.txt Status of This Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual contribution to the Internet Engineering Task Force (IETF). Comments should be submitted to the srvloc@srvloc.org mailing list. Distribution of this memo is unlimited. Day [Page i] INTERNET DRAFT SLP Exclusion Directive Exp. June 2003 Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . 2 1.1 Present SLPv2 Multicast Behavior . . . . . . . . . . 2 1.2 Optimizations Made by Exclusion Directive . . . . . 2 1.3 Terminology . . . . . . . . . . . . . . . . . . . . 3 2 Exclusion Extension Format . . . . . . . . . . . . . 4 2.1 Exclusion Extension Fields . . . . . . . . . . . . . 4 2.1.1 Size Field . . . . . . . . . . . . . . . . . . . . 4 2.1.1.1 Using the Size Field to Calcu- late Length of Entries . . . . . . . . . . . . . . . . . 5 2.1.2 Exclusion XID . . . . . . . . . . . . . . . . . . 5 2.1.3 Nonce . . . . . . . . . . . . . . . . . . . . . . 5 2.1.4 Exclusion Interval . . . . . . . . . . . . . . . . 5 2.1.5 Exclusion Entries . . . . . . . . . . . . . . . . 6 2.1.5.1 Dual-stack IP Environments . . . . . . . . . . . 6 2.1.6 Authentication Blocks . . . . . . . . . . . . . . 6 2.2 Exclusion Directive Functionality . . . . . . . . . 6 2.2.1 Exclusion Directive State Table (EDST) . . . . . . 7 3 Exclusion Directives in SLP v2 Request Messages . . . 8 3.1 Dummy Service Request Message with Exclu- sion Directive . . . . . . . . . . . . . . . . . . . . . 10 3.1.1 Format of Dummy Service Request . . . . . . . . . 11 3.1.2 Processing the Dummy Service Request . . . . . . . 12 3.1.3 Using the Exclusion Direc- tive and PR List Together . . . . . . . . . . . . . . . 12 4 Authenticating Exclusion Directives . . . . . . . . . 13 4.1 The Exclusion Directive Authentication Block . . . . 13 4.2 Exclusion Directive Authentication Rules . . . . . . 13 5 Using the NONCE Value to Prevent Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1 UA Use of the Nonce to Prevent Denial of Ser- vice Attack . . . . . . . . . . . . . . . . . . . . . . 15 5.2 DA and SA Use of the Nonce . . . . . . . . . . . . . 16 5.2.1 Zero-filled Nonce . . . . . . . . . . . . . . . . 16 5.3 Theory Behind the Nonce . . . . . . . . . . . . . . 16 6 Security Considerations . . . . . . . . . . . . . . . 16 7 Acknowledgements . . . . . . . . . . . . . . . . . . 17 8 References . . . . . . . . . . . . . . . . . . . . . 17 9 Author's Contact Information . . . . . . . . . . . . 17 10 Full Copyright Statement . . . . . . . . . . . . . . 18 Day [Page 1] INTERNET DRAFT SLP Exclusion Directive Exp. June 2003 1 Introduction The Service Location Protocol, Version 2 [1] allows the use of multicast and broadcast discovery requests. The SLP exclusion directive is an extension to SLP that optimizes the use of multicasting and broadcasting to find services on an intranet. This document hereafter refers to multicast discovery but all its contents apply to broadcast discovery as well. 1.1 Present SLPv2 Multicast Behavior Multicast discovery requests allow an SLP User Agent to discover services with no prior configuration. Multicast discovery requests are not sent reliably and must be retransmitted in order to find all services of the desired type on the network. When SLP v2 SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast, they contain a of previous respondents. Initially the is empty. When these requests are unicast, the is always empty. Any DA or SA which sees its address in the does not respond to the request (as specified in RFC 2608). The User Agent then retransmits the discovery request 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[1]. The PR list is an effective mechanism for suppressing duplicate responses in smaller environments. However, because of the way PR lists are encoded with the SLP v2 header, the PR List has a limit of as few as 90 IPv4 addressees, and even fewer IPv6 addresses. This means in most environments a User Agent may suppress duplicate responses from approximately 90 host addresses at best. 1.2 Optimizations Made by Exclusion Directive The Exclusion Directive extension presented in this document allows a User Agent (UA) to direct those Directory Agents (DAs) and Service Agents (SAs) from which it has already received responses not to respond to retransmissions of a particular query. Hence subsequent retransmissions only generate responses from agents from which the requester has not already received a response. Day [Page 2] INTERNET DRAFT SLP Exclusion Directive Exp. June 2003 This extension can be used in conjunction with the SLP v2 PR list. SAs and DAs which do not understand the Exclusion Directive extension will ignore it. With the use of the Exclusion Directive extension, SLP v2 User Agents may perform multicast discovery with a high degree of success and efficiency, even when the number of respondents reaches into the thousands. . 1.3 Terminology In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in RFC 2119 [2]. Day [Page 3] INTERNET DRAFT SLP Exclusion Directive Exp. June 2003 2 Exclusion Extension Format The fields in an Exclusion extension form an Exclusion Directive that tells receiving agents not to respond to a specific request from a specific host for a specific time interval. Each Exclusion Directive is fully contained within one SLP v2 extension block. However, a single SLP v2 request message may contain multiple Exclusion Directives. For example, a single Service Request may contain three Exclusion Directives within three distinct SLP v2 extension blocks. 2.1 Exclusion Extension Fields The Exclusion extension has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension ID = 0x000? | Next Extension Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset, contd.| size | Exclusion XID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exclusion Interval | Number of Entries | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exclusion Entries | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # auth blocks | authentication block (if any) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.1.1 Size Field The size field specifies the size, in bytes, of each address entry. A size value of 4 bytes MUST be encoded as an IP v4 address in network byte order. A size value of 16 bytes MUST be encoded as an IP v6 address in network byte order. Other address sizes are assumed to be opaque data and will not be interoperable among different imple- mentations Day [Page 4] INTERNET DRAFT SLP Exclusion Directive Exp. June 2003 2.1.1.1 Using the Size Field to Calculate Length of Entries The size of the Exclusion Entries field MUST be calcu- lated by multiplying the value of the Size field by the value of the Number of Entries field. 2.1.2 Exclusion XID The Exclusion XID identifies the SLP request to which the enclosing Exclusion Directive applies. An Exclusion Directive always applies to exactly one specific XID from exactly one host IP address. It is possible that the value of XID field in the Exclu- sion Directive and the XID in the SLP header of the mes- sage containing the Exclusion Directive will be differ- ent. This is a subtle but important point: the SLP v2 header XID and the Exclusion XID are not equivalent. See section 3.0 for details of how the exclusion XID works. 2.1.3 Nonce The Nonce adds a unique value to each Exclusion Directive that makes it difficult to mount a denial of service attack by replaying Exclusion Directives. The Nonce is a 128-bit field which MUST contain a cryptographic-quality random unique value; or alternatively must be filled with zero bytes. (If the Nonce is filled with zero bytes, it is ignored.) The usage of the Nonce is explained further in section 4.3. 2.1.4 Exclusion Interval The Exclusion Interval indicates the lifetime, in sec- onds, of the containing Exclusion Directive. The interval begins when the SA or DA receives the Exclusion Direc- tive. Exclusion Directives SHOULD have an interval from one to several seconds. However, the Exclusion Interval may need to be increased for unusually large networks or media with high latency characteristics, such as satel- lite links. Day [Page 5] INTERNET DRAFT SLP Exclusion Directive Exp. June 2003 2.1.5 Exclusion Entries The Exclusion Entries field is the list of host IP addresses that are subject to the containing Exclusion Directive. The length of the Exclusion Entries field is the number of IP addresses in the list multiplied by the size of each IP address. The size of each IP address is determined by the value of the size field. Each Exclusion Directive therefore may only contain IPv4 addresses or IPv6 addresses, but not both. 2.1.5.1 Dual-stack IP Environments In environments using both IPv4 and IPv6 addresses it may be necessary to deliver two Exclusion Directives where otherwise one would be sufficient. E.g., one Directive containing IPv4 addresses and another Directive contain- ing IPv6 addresses. One way to accomplish this is to pack two separate Exclusion Directives into a single SLP request. Another way involves using dummy request mes- sages to deliver Exclusion Directives. Dummy request mes- sages are covered in section 3.1 below. 2.1.6 Authentication Blocks The Number of Auth Blocks indicates how many authentica- tion blocks are contained in the containing Exclusion Directive. The format of the authentication block is cov- ered in section 4 below. Day [Page 6] INTERNET DRAFT SLP Exclusion Directive Exp. June 2003 2.2 Exclusion Directive Functionality The purpose of the Exclusion Directive is to cause SAs or DAs to silently discard specific SLP requests that origi- nate from specific IP addresses. This purpose aids in the use of multicasting to discover services in large network environments. The Exclusion Directive makes multicast discovery more reliable and efficient by: 1. Providing a more compact mechanism to silence previ- ous responders. 2. Magnifying the effect of the silencing mechanism by specifying a quiet interval. 2.2.1 Exclusion Directive State Table (EDST) When the Exclusion Directive is present in an SLP request, the receiving agent uses the directive to create and maintain state information that causes the receiving agent to ignore and discard matching requests (possibly including the request containing the Exclusion Direc- tive). The Exclusion Directive State Table (EDST) is the collec- tion of information describing all current Exclusion Directives received by the agent. EDST entries are a record with five fields: Source Address, Source Port, exclusion XID , exclusion nonce value, and expiration time. (The nonce value MAY be zero filled.) The Exclusion Directive only applies to SLP v2 messages that have the multicast flag set. The SA or DA MUST respond to SLP v2 messages that do not have the multicast flag set as specified in [1]. If the incoming request message matches a current record in the receiving agent's EDST, and if the incoming request's Multicast flag is set in the SLP header, the DA or SA MUST silently discard the message. When the Exclusion Interval of an Exclusion Directive has expired, the SA or DA MUST delete the corresponding record in its EDST and resume processing SLP v2 multicast Day [Page 7] INTERNET DRAFT SLP Exclusion Directive Exp. June 2003 request as if that Exclusion Directive was never received. If an incoming request does not contain an Exclusion Directive, the receiving agent MUST process that request without regard to the local EDST. (In other words, pro- cess the request normally.) 3 Exclusion Directives in SLP v2 Request Messages An SA or DA may encounter the Exclusion Directive in Ser- vice Request, Attribute Request, and Service Type Request messages. In each case, the request may also contain a PR list as described in [1]. A UA MUST NOT include an Exclusion Directive in a unicast SLP v2 request message. DAs and SAs MUST ignore Exclusion Directives that are erroneously included in unicast request messages. Day [Page 8] INTERNET DRAFT SLP Exclusion Directive Exp. June 2003 If the SA or DA supports the Exclusion Directive, it MUST perform the following steps when processing an SLP v2 Request message. 1. If the request message is unicast or if the receiv- ing agent does not recognize the Exclusion Direc- tive, go to step 6 below. 2. If the incoming request does not have an Exclusion Directive, proceed to step 6. 3. Extract the Exclusion Directive from the request. Search the Directive's Exclusion Entries list for the receiving agent's IP address. If not found, pro- ceed to step 6. 4. Extract the source address and port from the UDP header and the Exclusion XID and nonce from the Exclusion Directive. The receiving agent MUST ensure that its EDST contains a record for this directive, creating a new EDST record if necessary. (This step is also a convenient time to delete expired entries from the EDST.) 5. Extract the source address and port from the incom- ing request's UDP header. Extract the XID from the request's SLP v2 header. Extract the nonce from the Exclusion directive. Search the EDST for an entry containing matching values for these data (Optionally ignoring the nonce from the EDST entry if the incoming request does not contain an exclusion directive). Upon finding a matching EDST entry, silently discard the request. Otherwise continue. 6. If the SA or DA has not discarded the request up to this point, evaluate the request normally as out- lined in [1]. It is worth repeating that the Exclusion Directive only applies to SLP v2 request messages that have the R (Request Multicast) flag turned on in the SLP v2 header. Agents MUST NOT silently discard unicast request messages regardless of exclusion directives or EDST entries. Day [Page 9] INTERNET DRAFT SLP Exclusion Directive Exp. June 2003 Note that additional steps may be necessary if the Exclu- sion directive contains one or more authentication blocks. These steps are outlined in section 4. 3.1 Dummy Service Request Message with Exclusion Directive A "dummy" request message is one that has zero-length fields for the entire request body, exclusive of the SLP v2 header and the Exclusion directive. Using a dummy SLP request message for the sole purpose of transporting an Exclusion Directive may be helpful in two cases: 1. The Exclusion Directive is too large to fit within a single request datagram alongside the SLP header, service type, predicate, and other request data. However, it will fit in a datagram with just itself and the SLP header. 2. The Exclusion Directive is larger than the sum of the network MTU and the SLP Header. The agent can divide the Exclusion Entries list across two or more Exclusion Directives and transport those Directives within a corresponding number of dummy SLP request messages. This method can support Exclusion Entry lists that contain thousands of addresses. When an SA or DA receives a dummy SLP request that con- tains an Exclusion Directive, the receiving agent MUST extract the Exclusion Directive from the dummy request and ensure that the local EDST contains a record corre- sponding to the Exclusion Directive. This is described in section 3, step 4 above. A Dummy request message MUST have the R (Request Multi- cast) flag turned on in the SLP v2 header. This causes SLP v2 SAs and DAs that are unaware of the Exclusion Directive to silently discard dummy request messages due to a parsing error (instead of responding to the sending agent with an error code). Day [Page 10] INTERNET DRAFT SLP Exclusion Directive Exp. June 2003 3.1.1 Format of Dummy 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 (R flag on) (function = SrvRqst = 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of = 0 | length of = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of = 0 | length of = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of = 0 | Extension ID = Exclusion | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Extension Offset | size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exclusion XID | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce, cont'd. | Exclusion Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Entries | Exclusion Entries \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ # auth blocks | authentication block (if any)\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.1.2 Processing the Dummy Service Request Dummy Service Request messages MUST be processed as out- lined in section 3 above. The result is that the receiv- ing agents which support the Exclusion Directive will process the Directive, while all other agents will silently discard the message due to a parsing error. After processing the Exclusion Directive, the receiving agent will produce a parse error. Because the service request has the multicast flag set, the receiving agent will not send an error response to the originating agent. Note that if the Exclusion Directive contains an authen- tication block, the SA or DA SHOULD validate the signa- ture of the Exclusion Directive. Authentication of Exclu- sion Directives is covered in section 4. Day [Page 11] INTERNET DRAFT SLP Exclusion Directive Exp. June 2003 3.1.3 Using the Exclusion Directive and PR List Together The steps below show how to use the Exclusion Directive in combination with the SLP PR list to perform multicast discovery (substitute actual XIDs in real usage): 1. Send a new Service Request with no PR list and no Exclusion Directive; process the replies and remem- ber the respondents as RL1. 2. Build an exclusion list and remember it as list EL1. 3. Immediately re-transmit the Service Request from (1) with no PR list but with an Exclusion Directive that contains Exclusion List EL1; process the replies and remember the respondents as RL2. 4. The intersection of EL1 and RL2 are agents that do not support the Exclusion Directive. Create PRL1 = EL1 n RL2. Build EL2 = RL2 - PRL1. 5. Immediately re-transmit the Service Request from (3) including PRL1 in the SLP header and substituting EL2 for EL1 in the Exclusion Directive. If no responses the discovery cycle is complete. 6. Repeat the previous thre steps n times using ELn-1, RLn, PRLn-1, and ELn until the UA receives no responses for the configured timeout period. In steps 1 - 6 above, it is important that each Service Request (steps 1, 3, and 5) have the same XID in the SLP Header ; and equally that each Exclusion Directive also has the same value in the XID field. Day [Page 12] INTERNET DRAFT SLP Exclusion Directive Exp. June 2003 4 Authenticating Exclusion Directives To prevent denial of service attacks against UAs, all agents that recognize the Exclusion Directive SHOULD sup- port authentication of the Exclusion Directive. Authenticating Exclusion Directives places the additional burden upon the User Agent of signing data. In standard SLP v2, UAs only need to verify signatures. The addi- tional ability to generate signatures means that UAs must be issued private key material. 4.1 The Exclusion Directive Authentication Block The format of the Exclusion Directive Authentication Block is the same as that used by SLP v2 [1]. 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... \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Day [Page 13] INTERNET DRAFT SLP Exclusion Directive Exp. June 2003 4.2 Exclusion Directive Authentication Rules To sign or verify the signature of an Exclusion Direc- tive, the SLP agent MUST use the following components of the Exclusion Directive as if they were a single continu- ous byte-aligned buffer: ¸ 16-bit Exclusion XID ¸ 32-bit Nonce ¸ 16-bit Exclusion Interval ¸ 8-bit Exclusion Entry size ¸ 16-bit Number of Entries ¸ Variable-length Exclusion Entries. 5 Using the NONCE Value to Prevent Replay Attacks Despite the use of signatures to authenticate Exclusion Directives, UAs may still be vulnerable to a replay denial of service attack. To prevent this possibility, SLP Agents that recognize the Exclusion directive SHOULD make use of the nonce value as described in this section. Every Exclusion Directive contains a 128-bit nonce field, which MUST contain a 128-bit cryptographicly random value or be filled with zeros. If the nonce is filled with zeroes, the UA is open to a denial-of service attack. Because the nonce field is included in signature genera- tion and validation, each signed Exclusion Directive can be cryptographically unique. Unsigned Exclusion Direc- tives can also be cryptographically unique but their source can be spoofed. Day [Page 14] INTERNET DRAFT SLP Exclusion Directive Exp. June 2003 By using the nonce correctly, Exclusion Directives can be specific to: 1. The source address and port of the requesting UA. 2. The XID of the request. 3. A cryptographically unique value for each and every request. To make this work, SAs and DAs MUST include the nonce value, along with the UA source address and the request XID when deciding whether or not an Exclusion Directive applies to a request message. 5.1 UA Use of the Nonce to Prevent Denial of Service Attack The UA is the SLP component vulnerable to a denial of service attack so it is responsible for using an appro- priate algorithm to generate a nonce with the requisite random characteristics. For each Exclusion Directive: 1. Generate a random 128-bit integer to use as the nonce. 2. Initialize an Exclusion Directive, including the XID of the request that is subject to response suppres- sion. 3. Insert the nonce value from (1) into the Exclusion Directive. 4. Optionally sign the Exclusion Directive as outlined in the section on Authentication above. 5. Use a Exclusion Directive containing the nonce in all requests and dummy Service Requests for the XID in step (2). 6. IMPORTANT - use a DIFFERENT, cryptographically gen- erated nonce for each request XID for which you are issuing an Exclusion directive. Day [Page 15] INTERNET DRAFT SLP Exclusion Directive Exp. June 2003 5.2 DA and SA Use of the Nonce SA's DAs that recognize the Exclusion Directive MUST use the nonce value to initialize EDST entries and to evalu- ate Exclusion Directives in request messages. 5.2.1 Zero-filled Nonce UAs that don't have the ability to generate unique nonce values MUST fill the nonce field of the Exclusion Direc- tive with zeros. This opens the agent up to a denial of service attack, however. (See below). 5.3 Theory Behind the Nonce The nonce is a simple mechanism to make it as difficult as possible for an attacker to predict the composition of SLP service requests that a particular UA may issue in the near future. Most UA's use the XID field in the SLP 2 header as a sequential counter. Hence an attacker that has a copy of a recent SLP request can guess the XID of the next request the agent will make. Using the Exclusion Direc- tive, an attacker can cause DA's and SA's not to respond to subsequent SLP requests made by the attacked agent. However, the inclusion of the nonce value in the Exclu- sion Directive makes it infeasible for an attacker to guess the composition of future requests made by the UA. This is true because the nonce, unlike the XID, is a ran- dom value. Also, the nonce is large enough to make guess- ing its value in the next request too difficult for the attacker. 6 Security Considerations Implementing the Exclusion Directive without using the nonce value opens SLP v2 UAs up to a trivial denial of service attack, which would nullify the ability of the UA to perform discovery. Implementing the Exclusion Directive with authentication but without using the nonce value may leave the UA open to a more sophisticated replay attack using previously Day [Page 16] INTERNET DRAFT SLP Exclusion Directive Exp. June 2003 signed and multicast request messages. UAs that support the Exclusion Directive SHOULD authenti- cate their requests as outlined in section 4 and SHOULD include the nonce value in all Exclusion Directives. SAs and DAs that support the Exclusion Directive SHOULD be able to verify signed Exclusion Directives and MUST store the nonce value in the EDST entry for that direc- tive. Nonce values generated by UAs MUST be cryptographically unique and random values if they are to provide any safe- guard against a replay attack. 7 Acknowledgements Erik Guttman has provided a great deal of feedback and improvements to this document. The srvloc working group also contributed to the development of this document, especialy Kevin Arnold, James Kempf, Ira McDonald, Evan Hughes, Terry Lambert, and others. Thomas Narten recom- mended some important changes during the review process. 8 References 1. Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol Version 2", RFC 2608, June 1999. 2. Bradner, S,. "Key Words for Use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997 9 Author's Contact Information Michael Day IBM 3039 Cornwallis Road Research Triangle Park, NC 27709 Phone: 919 543-4283 Email: mdday@us.ibm.com Day [Page 17] INTERNET DRAFT SLP Exclusion Directive Exp. June 2003 10 Full Copyright Statement Copyright (C) The Internet Society (2000-2002). 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, pro- vided 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 refer- ences to the Internet Society or other Internet organiza- tions, except as needed for the purpose of developing Internet standards in which case the procedures for copy- rights 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 suc- cessors 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 WAR- RANTIES, 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 MER- CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Day [Page 18]