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 <PRList> of previous respondents. Initially the
<PRList> is empty. When these requests are unicast, the <PRList> is
always empty.
Any DA or SA which sees its address in the <PRList> does not respond
to the request (as specified in RFC 2608).
The message is then re transmitted 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 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 <PRList> = 0 | length of <service-type> = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> = 0 | length of <predicate> = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <SLP SPI > = 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]