Internet Engineering Task Force Michael Day INTERNET DRAFT IBM 19 March Expires in six months Exclusion Extension for Service Location Protocol v2 draft-day-svrloc-exclusion-01.txt Status of This Memo 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. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The Service Location Protocol, Version 2 [1] allows the use of multicast discovery requests. Multicast discovery requests allow an agent to discover services with no prior configuration by issuing a request which will be recognized by all SLP Service Agents supporting the requested service. However, multicast discovery requests are not sent reliably, so they may be re transmitted in order to find most (if not all) services of the desired type on the network. It is necessary to suppress duplicate responses to scale multicast discovery requests in environments where there are hundreds or thousands of agents. SLPv2 includes a mechanism for suppressing duplicate responses, but which has various limitations. This document defines an SLPv2 extension that provides a superior alternative. Day Expires: 19 September 2001 [Page 1] Internet Draft SLP Exclusion Extension March 2001 Table Of Contents 1. Introduction . . . . . . . . . . . . .. . . . . . . . . . . . . . 2 2. Exclusion Directive Extension Format. . . . . . . . . . . . . . . 2 3. Exclusion Directives in Request Messages. . . . . . . . . . . . . 6 4. Authenticating Exclusion Directives . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Contact Information . . . . . . . . . . . . . . . . . . . . . . . . 12 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 12 Introduction The Service Location Protocol, Version 2 [1] allows the use of multicast requests. Multicast discovery requests allow an agent to discover services with no prior configuration. Multicast discovery requests are not sent reliably and may be re transmitted in order to find most (if not all) services of the desired type on the network. When SLP 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 message is then re transmitted 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, there is a limit of as few as 90 IPv4 addressees within the PR list (and even fewer IPv6 addresses). This means in most environments a User Agent may suppress duplicate responses from approximately 90 host addresses at best. The Exclusion extension presented in this document allows a User Agent (UA) to notify those Directory Agents (DAs) and Service Agents Day Expires: 19 September 2001 [Page 2] Internet Draft SLP Exclusion Extension March 2001 (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 not already heard from by the UA. This extension can be used in conjunction with the SLP v2 PR list. SAs and DAs which do not understand the Exclusion extension will ignore it. With the use of the Exclusion extension, SLP v2 User Agents may perform multicast discovery with a high degree of success, even in very large networks. 1.1 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]. 2.0 Exclusion extension Format Taken together, the fields in the Exclusion extension form an Exclusion directive. The directive tells receiving agents not to respond to a specific multicast request from a specific host for a specific time interval. Note that there may be more than exclusion directive delivered within an SLP v2 message. 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.|S| reserved | Exclusion XID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exclusion Interval | Number of Entries | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exclusion Entries | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # auth blocks | authentication block (if any) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Day Expires: 19 September 2001 [Page 3] Internet Draft SLP Exclusion Extension March 2001 2.1 Exclusion Extension Fields The extension itself, defined above, comprises the Exclusion directive. 2.1.1 Flag Value S 0x20 SIX. When set, Each entry in the Exclusion Entries field is a 16-byte IPv6 address encoded in network byte order. When the SIX flag is clear, each entry in the Exclusion Entries field is a 4-byte IPv4 address encoded in network byte order. 2.1.2 Exclusion XID The Exclusion XID identifies the XID (from the SLP v2 header) to which the exclusion directive applies. An exclusion directive always applies to a specific XID from a specific host. It is possible that the XID in the Exclusion directive and the XID in the SLP header of the message containing the Exclusion directive will be different. 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. In short, this feature allows the UA to use a current request to suppress responses to a future request. 2.1.3 Nonce The Nonce is a 128-bit field that SHOULD contain a cryptographically unique and random value for each exclusion directive. UAs not using the Nonce MUST set this field to zeroes. The Nonce makes replay attacks more difficult by making each Exclusion directive cryptographically unique. The usage of the Nonce is explained further in section 4.3. 2.1.4 Exclusion Interval The Exclusion Interval indicates the lifetime, in seconds, of this exclusion directive. The interval begins when the SA or DA receives the exclusion directive. Exclusion directives are intended to have a lifetime of a few seconds up to one or two minutes in high-latency network environments. 2.1.5 Exclusion Entries The Exclusion Entries field is the list of host IP addresses that are subject to this exclusion directive. The length of the Exclusion entries field is the number of IP addresses in the list multiplied by Day Expires: 19 September 2001 [Page 4] Internet Draft SLP Exclusion Extension March 2001 the size of each IP address. The size of each IP address is determined by the SIX flag. When clear, each address is four bytes. When set, each address is 16 bytes. In environments using both IPv4 and IPv6 addresses you will need to deliver two exclusion directives where otherwise you would only need to deliver one. E.g., one directive containing IPv4 addresses and another directive containing IPv6 addresses. One way to accomplish this is to pack two separate exclusion directives in each message. Another way involves using dummy request messages to deliver exclusion directives. Dummy request messages are covered in section 3.1 below. 2.1.6 Authentication Blocks The Number of Auth Blocks indicates how many authentication blocks are contained in this exclusion directive. The format of the authentication block is covered in section 4 below. 2.2 Exclusion Directive Functionality The purpose of the exclusion directive is to cause SAs or DAs to silently discard specific SLP requests. When the exclusion directive is present in a message, the receiving agent uses the directive to create and maintain state information that causes certain requests to be ignored and discarded (possibly including the request containing the exclusion directive). The Exclusion Directive State Table (EDST) is the collection information, stored at the receiving SA or DA, from all active exclusion directives. EDST entries are a tuple with five values: Source Address, Source Port, message XID , 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 message matches an active entry from the local EDST, the the SA or DA will silently discard the message. When the Exclusion Interval of an exclusion directive has expired, the SA or DA will discard that exclusion directive and resume processing SLP v2 multicast messages as if that exclusion directive was never received. It is important to emphasize that an incoming request might not have an exclusion directive. Even so, the receiving agent should evaluate the request against active exclusion directives. Day Expires: 19 September 2001 [Page 5] Internet Draft SLP Exclusion Extension March 2001 3.0 Exclusion Directives in SLP v2 Request Messages An SA or DA may encounter the exclusion directive in Service Request, Attribute Request, and Service Type Request messages. In each case, the message may also contain a PR list. 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. 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 SA or DA does not recognize the Exclusion directive, go to step 6 below. 2) If the incoming request does not have an exclusion directive, proceed to step 5 below. 3) Search the incoming directive's Exclusion Entries list for the receiving agent's IP address. If not found, proceed to step 5 below. 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 an entry for this directive, creating a new EDST entry 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 incoming requests UDP header. Extract the XID from the SLP v2 header. If the incoming request has an exclusion directive, extract the nonce from the directive. Search the EDST for an entry containing matching values for these data (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 to step 6 below. 6) If the SA or DA has not discarded the request up to this point, evaluate the request normally as outlined in [1]. Its 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. Note that additional steps may be necessary if the Exclusion directive contains one or more authentication blocks. These steps are outlined in section 4. Day Expires: 19 September 2001 [Page 6] Internet Draft SLP Exclusion Extension March 2001 3.1 Dummy Service Request Message with Exclusion Directive If the UA needs to suppress responses from several hundred or perhaps thousands of SAs and DAs, it may send "dummy" request messages whose sole purpose is to deliver exclusion directives that cause receiving agents to initialize EDST entries for a pending request retransmission. 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. The only time a dummy request message is necessary is when the list of excluded agents is too large to fit within a single (datagram) request message. A Dummy request message MUST have the R (Request Multicast) 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). 3.2 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 |S| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exclusion XID | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce, cont'd. | Exclusion Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Entries | Exclusion Entries \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ # auth blocks | authentication block (if any)\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.3 Processing the Dummy Service Request Dummy Service Request messages MUST be processed as outlined in section 3 above. The result is that the receiving agents that support the exclusion directive will process the directive, while all other agents will silently discard the message due to a parsing error. Day Expires: 19 September 2001 [Page 7] Internet Draft SLP Exclusion Extension March 2001 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 authentication block, the SA or DA SHOULD validate the signature of the Exclusion Directive. Authentication of Exclusion directives is covered in section 4. 3.4 Using the Dummy Service Request to Suppress Responses If the UA believes it may receive several hundred responses to a multicast SLP request, it can use dummy Service Request messages to suppress responses, as follows (substitute actual XIDs in real usage): 1) Send the request with no PR list and no Exclusion list; process replies and remember the respondents as list RL1 2) Build an exclusion list and remember it as list EL1 3) Send the request with no PR list, and Exclusion List = EL1 (or a dummy request with the same xid) process the replies and remember the list as RL2 4) The intersection of EL1 and RL2 is the set of respondents that do not support exclusion lists. Create ELi = RL2 - (RL1 n EL1) and PRLi = (RL1 n EL1) 5) Send the request with PR list = PRLi and Exclusion List = ELi process the replies and remember the respondents as RLj if there are no replies - done 6) Create Exclusion List ELi+1 = RLj - (RLj n ELi) Previous Responder List PRLi+1 = PRLi + (RLj n ELi) Repeat step 5 4.0 Authenticating Exclusion Directives To prevent denial of service attacks against UAs, all agents that recognize the Exclusion directive SHOULD support 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 additional ability to generate signatures means that UAs must be issued private key material. Day Expires: 19 September 2001 [Page 8] Internet Draft SLP Exclusion Extension March 2001 4.1 The Exclusion Authentication Block The format of the Exclusion 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... \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2 Exclusion Directive Authentication Rules To sign or verify the signature of an Exclusion Directive, the SLP agent MUST use the following components of the Exclusion Directive as if they were a single continuous byte-aligned buffer: . 16-bit Exclusion XID . 32-bit Nonce . 16-bit Exclusion Interval . 16-bit Number of Entries . Variable-length Exclusion Entries. 4.3 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 SHOULD contain a 128-bit cryptographicly unique and random value. Because the nonce field is included in signature generation and validation, each signed exclusion Directive can be verifiably cryptographically unique. Unsigned exclusion directives can also be verifiably unique but their source cannot be determined with certainty. 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 Day Expires: 19 September 2001 [Page 9] Internet Draft SLP Exclusion Extension March 2001 3) A cryptographically unique value that is guaranteed to be different 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. 4.4 UAs Usage of the Nonce to Prevent Replay Attacks The key to preventing replay attacks lies on the correct usage of the nonce by the UA. UA's SHOULD use the nonce as follows: For each Exclusion Directive: 1) Generate a random, cryptographically unique 128-bit nonce. 2) Initialize an Exclusion directive, including the XID of the request that is subject to response suppression. 3) Insert the nonce into the exclusion directive. 4) Sign the exclusion directive as outlined above. 5) Use a signed exclusion directive containing the nonce in all requests and dummy Service Requests for the XID in step 2. 6) IMPORTANT - use a DIFFERENT, cryptographically generated nonce for each request XID for which you are issuing an Exclusion directive. 4.5 SA and DA Usage of the Nonce to Prevent Replay Attacks SA's DAs that recognize the exclusion directive MUST use the nonce value to initialize EDT entries and to evaluate exclusion directives in request messages. When encountering an exclusion directive with an authentication block, the SA or DA SHOULD: 1) Verify the signature of the Exclusion directive. 2) If the signature is valid, continue with the steps outlined in section 3 above. 3) Otherwise silently discard the message. 4.6 Zero-filled Nonce UAs that don't have the ability to generate cryptographically unique nonce values MUST fill the nonce field of the exclusion directive with zeros. This opens the agent up to a denial of service attack, however. (See below). Day Expires: 19 September 2001 [Page 10] Internet Draft SLP Exclusion Extension March 2001 4.7 Ignoring the Nonce SAs and DAs MAY ignore the nonce when evaluating incoming requests that do not contain an exclusion directive against local EDST entries. However, this opens UAs up to a denial of service attack and is not recommended. 5. Security Considerations Implementing the Exclusion directive without authentication 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 signed and multicast request messages. Using the nonce field (even without authentication of exclusion directives) renders a denial of service attack significantly more difficult than it would be otherwise. Including a cryptographically uinique and random nonce value in the exclusion directive is a simple way to decreate the vulnerabilty of the SLP agents to a denial of service attack. UAs that support the Exclusion directive SHOULD authenticate 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 directive. Nonce values generated by UAs SHOULD be cryptographically unique and random values if they are to provide any safeguard against a replay attack. 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 also recommended some beneficial changes during the review process. 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 Day Expires: 19 September 2001 [Page 11] Internet Draft SLP Exclusion Extension March 2001 Author's Contact Information Michael D. Day IBM 3039 Cornwallis Road Research Triangle Park, NC 27709 Phone: 919 543-4283 Email: mdday@us.ibm.com Full Copyright Statement Copyright (C) The Internet Society (2000-2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing 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." Day Expires: 19 September 2001 [Page 12]