Internet DRAFT - draft-day-srvloc-exclusion
draft-day-srvloc-exclusion
Internet Engineering Task Force Michael Day
INTERNET DRAFT IBM
23 December 2002 Expires in six months
Exclusion Extension for Service Location Protocol v2
draft-day-srvloc-exclusion-02.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. May 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 . . . . . . . 11
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 . . . . . . 14
5 Using the NONCE Value to Prevent Replay Attacks
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1 UA Use of the Nonce to Prevent Denial of Ser-
vice Attack . . . . . . . . . . . . . . . . . . . . . . 16
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. May 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 <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 User Agent then retransmits the discovery request 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, 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. May 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. May 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. May 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. May 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. May 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. May 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. May 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. 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 (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. May 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. May 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 <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 | 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. May 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 and 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. May 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. May 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. May 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. May 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. May 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. May 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]
