Internet Engineering Task Force Michael Day INTERNET DRAFT Legato Systems 14 July 2000 Expires in six months Exclusion Extension for Service Location Protocol v2 draft-day-svrloc-exclusion-00.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 provide a fast way for an agent to discover services with no prior knowledge other than the service type. However, multicast discovery requests may need to be recast in order to ensure a complete set of discovery responses. When this is the case, it is useful to suppress duplicate responses. SLP v2 has a built-in mechanism for suppressing duplicate responses that is sufficient for many environments. However, in certain environments a more scalable suppression mechanism is needed. This document defines an SLP extension that enhances the ability of an SLP agent to suppress duplicate responses to multicast requests. 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, simply by issuing a Day Expires: 14 Jan 2001 [Page 1] Internet Draft Exclusion Directive for SLP v2 July 2000 request which will be recognized by service agents supporting the requested service. Multicast discovery requests are not sent reliably, so they may be retransmitted in order to attempt to find more (if not all) services of the desired type on the network. It is necessary to suppress duplicate responses in order to allow multicast discovery protocols to scale to discovery of more than a limited number of services. SLPv2 includes a mechanism for suppressing duplicate responses, which has various limitations. This document defines an SLPv2 extension that provides a superior alternative. Table Of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Exclusion Directive Extension Format . . . . . . . . . . . . . 4 3. Exclusion Directives in Request Messages . . . . . . . . . . . 6 4. Authenticating Exclusion Directives . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . .11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . .11 References . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 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, simply by issuing a request which will be recognized by service agents supporting the requested service. Multicast discovery requests are not sent reliably, so they may be retransmitted in order to attempt to find more (if not all) services of the desired type on the network. It is necessary to suppress duplicate responses in order to allow multicast discovery protocols to scale to discovery of more than a limited number of services. SLPv2 includes a mechanism for suppressing duplicate responses, which has various limitations. This document defines an SLPv2 extension that provides a superior alternative. When SLP SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast, they contain a of previous responders. Initially the is empty. When these requests are unicast, the is always empty. Any DA or SA which sees its address in the MUST NOT respond Day Expires: 14 Jan 2001 [Page 2] Internet Draft Exclusion Directive for SLP v2 July 2000 to the request. The message SHOULD be retransmitted until the causes no further responses to be elicited or the previous responder list and the request will not fit into a single datagram or until CONFIG_MC_MAX seconds elapse[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 addresses within the PR list. This means that in most environments a User Agent may suppress duplicate responses from approximately 90 host addresses at best. The Exclusion directive extension presented in this document is a mechanism to allow a User Agent to suppress duplicate responses from hundreds or thousands of host addresses. It can be used in conjunction with the SLP v2 PR list. Service Agents and Directory Agents which do not understand the Exclusion extension may safely ignore it. With the use of the Exclusion directive, SLP v2 User Agents may perform multicast discovery in a reliable manner. 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 Service Agents and User Agents that support the Exclusion directive MUST view each received extension as an "exclusion directive" with a finite lifetime. This means that the receiving agent MUST maintain state information for each valid exclusion directive for the lifetime of that directive. 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.|N|F|S| reserved| Exclusion Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exclusion XID | Number of Entries | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exclusion Entries | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # auth blocks | authentication block (if any) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Day Expires: 14 Jan 2001 [Page 3] Internet Draft Exclusion Directive for SLP v2 July 2000 Flag Value Explanation N 0x80 NONCE indicates that the first 16 bytes of the Exclusion Entries field contains a 128-bit cryptographic value that can be used to prevent replay attacks. See Section x.x. F 0x40 FOUR means that each entry in the Exclusion Entries field is a 4-byte IPv4 address encoded in network byte order. S 0x20 SIX means that each entry in the Exclusion Entries field is a 16-byte IPv6 address encoded in network byte order. The FOUR and SIX flags are mutually exclusive - if they are both set it is an error and the SA or DA MUST ignore the Exclusion directive. If neither the FOUR nor the SIX flags are set it is an error and the SA or DA MUST ignore the Exclusion directive. The Exclusion Interval indicates the lifetime, in seconds, of this exclusion directive. The interval begins when the SA or DA receives the exclusion directive. The Exclusion XID limits the application of the exclusion directive to SLP v2 multicast messages from the source host that have an XID equal to the exclusion XID. In other words, each exclusion directive only applies to SLP v2 messages with a specific XID from a specific UA. The Exclusion Entries is the list of addresses that are subject to this exclusion directive. The SA or DA MUST derive the length of the Exclusion Entries field by multiplying the Number of Entries by four bytes if the FOUR flag is set, or by 16 bytes if the SIX flag is set. For example, if the Exclusion Entries included 3 IPv4 addresses, the value would be 12 bytes long and the Number of Entries field would be set to 3. If the 'N' flag was set, the first 16 bytes would be set to the Nonce value. In this case, there would be 28 bytes in Exclusoin Entries field and the Number of Entries field would be set to 7. The SA or DA receiving this message knows to start searching for its address starting after the first four entries, as the 'N' flag is set. The Number of Auth Blocks indicates how many authentication blocks are contained in this exclusion directive. The format of the Exclusion authentication block is covered later in this document. 2.1 Exclusion Directive Functionality The Exclusion directive works in the same manner as the SLP v2 PR Day Expires: 14 Jan 2001 [Page 4] Internet Draft Exclusion Directive for SLP v2 July 2000 list, with two important differences. When a Service Agent or Directory Agent recognizes an Exclusion directive, the agent MUST search the directive for its (the agent's) address. If the agent's address is within the Exclusion directive, then that agent MUST initialize appropriate state information and MUST silently discard the message containing the exclusion directive. State information that must be maintained by the SA or DA for each valid exclusion directive MUST include the Exclusion interval, the Exclusion XID, and the source address and port of the host that sent the Exclusion extension. If the exclusion directive has the NONCE flag set, then the SA or DA MUST include the accompanying cryptographic value with the state information for that exclusion directive. When an SA or DA that supports the Exclusion extension receives a new SLP v2 message with the Multicast flag set, it MUST first evaluate the new message against all active exclusion directives. Exclusion Directive State Table (EDST) entries are a tuple with five values: Source Address, Source Port, message XID and Expiration Time, and nonce value. The nonce value MAY be null for some Exclusion directives, if the requesting UA did not set the NONCE flag in the request message that created the EDST entry. A SA or DA MUST check to see if an incoming message has a source address, source port and XID which is included in its EDST. If so, the message is discarded. When the Exclusion Interval of an exclusion directive has expired, the SA or DA MUST discard that exclusion directive and resume processing SLP v2 multicast messages as if that exclusion directive was never received. Note that the SA or DA may be required to verify signatures of exclusion directives before accepting them and storing the appropriate state information. This topic is covered in 4. 2.2 Exclusion Only Applies to Multicast Messages The Exclusion extension 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]. 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. If the SA or DA supports the Day Expires: 14 Jan 2001 [Page 5] Internet Draft Exclusion Directive for SLP v2 July 2000 Exclusion directive, it MUST perform the following steps when processing an SLP v2 Request message. 1) If no Exclusion directive is present in the request, or if the SA or DA does not recognize the Exclusion directive, evaluate the request normally as outlined in [1]. 2) If SA or DA address is on the PR list, silently discard the request, regardless of whether or not it has an Exclusion directive (Standard SLP v2 behavior). 3) If SA or DA address is not on the PR list, check the XID and source address of the request against active EDST entries. If EDST entry applies to this request, silently discard the request. An EDST entry applies to a request if and only if the entry has not expired, it contains the source address and port of the requestmessage; it contains the same XID as the request message, and if the request message contains a nonce value in its Exclusion directive, the nonce value in the EDST entry must be the same. 4) If no EDST entry applies to this request, investigate the Exclusion Entries field contained within the request. If the SA or DA address is in the Exclusion Entries field, the agent MUST initialize a new EDST entry for the exclusion directive, including the lifetime, XID, source address, and port, and possibly the nonce value. Silently discard the request. 5) If the SA or DA has not discarded the request up to this point, evaluate the request normally as outlined in [1]. Note that additional steps may be necessary if the Exclusion directive contains one or more authentication blocks. 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 need to send "dummy" request messages whose sole purpose is to deliver Exclusion directives. Doing so allows extra room in the request message to include more addresses in the Exclusion Entries field. 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. A Dummy request message MUST have the R (Request Multicast) flag Day Expires: 14 Jan 2001 [Page 6] Internet Draft Exclusion Directive for SLP v2 July 2000 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. 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 |N|F|S| reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interval cont | Exclusion XID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Entries | Exclusion Entries \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # auth blocks | authentication block (if any) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that in the SLP v2 header the R bit MUST be turned on. The Exclusion directive begins immediately after the length of the SLP SPI. This offset must be consistent with the Next Extension offset in the SLP v2 header. 3.3 Processing the Dummy Service Request An SA or DA receiving a dummy service request message MUST process the message as follows: 1) If the SA or DA does not recognize the Exclusion directive, silently discard the message due to a parsing error. 2) If the SA or DA recognizes the Exclusion directive, check the message for the presence of an Exclusion directive. If one is not present, silently discard the message due to a parsing error. 3) If the SA or DA locates an Exclusion directive in the dummy request, and if the SA's or DA's address is contained within the Exclusion directive, the SA or DA MUST initialize a new EDST entry for for the directive, including the lifetime, XID, ource address and port of the request message, and possibly the nonce value if the Exclusion directive contains one. Further, Day Expires: 14 Jan 2001 [Page 7] Internet Draft Exclusion Directive for SLP v2 July 2000 the SA or DA MUST evaluate any subsequent request messages against that EDST entry for as long as it is valid. Note that if the Exclusion directive contains an authentication block, the SA or DA SHOULD validate the signature of the Exclusion Directive and, if the NONCE flag is set, MUST include the nonce value contained within the directive in EDST entry for that directive. Authentication of Exclusion directives is covered in section 4. Because of the way step 3 above works, the UA can suppress responses from SAs or DAs without including the addresses of those agents within the actual Service or Attribute Request message. The reason this works is that the Exclusion directive in the dummy Service Request can contain the XID of the real Service Request message. 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 responders 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 responders 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 responders 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: 14 Jan 2001 [Page 8] Internet Draft Exclusion Directive for SLP v2 July 2000 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 Interval 16-bit Exclusion XID 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, UA's may still be vulnerable to replay denial-of-service attacks. To prevent this possibility, SLP Agents that recognize the Exclusion directive SHOULD make use of the NONCE value as described in this section. When the NONCE flag is set in an Exclusion directive, the first 16 bytes of the Exclusion Entries field contains a 128-bit cryptographic value that corresponds to exactly one exclusion directive. Because the Exclusion Entries field is included in signature generation and validation, each Exclusion Directive can be verifiably cryptographically unique. 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 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. Day Expires: 14 Jan 2001 [Page 9] Internet Draft Exclusion Directive for SLP v2 July 2000 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 first 16 bytes of the Exclusion Entries field and set the NONCE flag in the Exclusion directive. 4) Sign the Exclusion directive as outlined above. 5) Use the signed Exclusion directive containing the nonce in all requests and dummy Service Requests for the XID in step 2. 6) IMPORTANT - use a DIFFERENT, randomly-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, when present, to initialize and to evaluate Exclusion directives in request messages. When encountering an Exclusion directive with an autentication block, the SA or DA must: 1) Verify the signature of the Exclusion directive. 2) Extract the nonce from the first 16 bytes of the Exclusion Entries field. 3) Evaluate the XID, source address, AND the nonce against existing valid Exclusion directives that have not expired. Upon finding a match, silently discard the request message. 4) If the message has not yet been discarded, verify that the SA or DA address is included in the Exclusion Entries list. If not, evaluate the request message normally as outlined in [1]. 5) If the Exclusion directive is valid AND the SA or DA address IS included in the Exclusion Entries, AND no existing directives match it, initialize state information for a new Exclusion directive. Include the lifetime, XID, source address, AND nonce in the state information. Silently discard the message. 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 Day Expires: 14 Jan 2001 [Page 10] Internet Draft Exclusion Directive for SLP v2 July 2000 using the nonce value may leave the UA open to a more sophisticated denial of service attack that replays previously signed and multicast request messages. 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 MUST be able to verify signed Exclusion Directives and MUST store the nonce value when it is present in the EDST entry for that directive. Nonce values generated by UAs SHOULD be cryptographically random values if they are to provide any safeguard against a replay attack. Acknowledgements Erik Guttman had 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, 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 Author's Contact Information Michael Day Legato Systems 1201 North 800 East Orem, Utah USA 84097 Phone: 801 437-8250 Email: mday@legato.com Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to Day Expires: 14 Jan 2001 [Page 11] Internet Draft Exclusion Directive for SLP v2 July 2000 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: 14 Jan 2001 [Page 12]