Return to draft-day-srvloc-exclusion-02.nr.txt CVS log

Up to [Pegasus] / pegasus_unsupported / slp_client / doc

BUG#: 4730
TITLE: move slp_client out of Pegasus to Pegasus_Unspported

DESCRIPTION: Commit the entire tree to pegasus_unsupported

.\"-----------------------------------------------------------------
.\" Registers to store heading levels as variables
.\"-----------------------------------------------------------------
.nr head1 0 1
.nr head2 0 1
.nr head3 0 1 
.nr head4 0 1
.nr head5 0 1
.nr head6 0 1

.\"-----------------------------------------------------------------
.\" Return to header level 1, 2, etc. 
.\" resets the level registers and indent
.\"-----------------------------------------------------------------
.de RETURN_HDR_1
.nr head2 0 1
.nr head3 0 1 
.nr head4 0 1
.nr head5 0 1
.nr head6 0 1
.in 0 
\.HDR_1 \\$1 
..

.de RETURN_HDR_2
.nr head3 0 1 
.nr head4 0 1
.nr head5 0 1
.nr head6 0 1
.in 0 
\.HDR_2 \\$1
..
 
.de RETURN_HDR_3
.nr head4 0 1
.nr head5 0 1
.nr head6 0 1
.in 0 
\.HDR_3 \\$1
..

.de RETURN_HDR_4
.nr head5 0 1
.nr head6 0 1
.in 0 
\.HDR_4 \\$1
..

.de RETURN_HDR_5
.nr head6 0 1
.in 0 
\.HDR_5 \\$1
..

.\"-----------------------------------------------------------------
.\" Create a level 1, 2, etc,.  heading 
.\" resets indent, creates a TOC entry
.\" Parameter is the title of the heading
.\"-----------------------------------------------------------------
.de HDR_1
.sp 1
.in 0 
\\n+[head1]\\  \\$1
.XS
\\n[head1]\\  \\$1
.XE
.in 3
.. 


.de HDR_2
.sp 1
.in 0 
\\n[head1]\\.\\n+[head2]\\ \\$1
.XS
\\n[head1]\\.\\n[head2]\\ \\$1
.XE
.in 3
.. 

.de HDR_3
.sp 1
.in 0 
\\n[head1]\\.\\n[head2]\\.\\n+[head3]\\ \\$1
.XS
\\n[head1]\\.\\n[head2]\\.\\n[head3]\\ \\$1
.XE
.in 3
.. 

.de HDR_4
.sp 1
.in 0 
\\n[head1]\\.\\n[head2]\\.\\n[head3]\\.\\n+[head4]\\ \\$1
.XS
\\n[head1]\\.\\n[head2]\\.\\n[head3]\\.\\n[head4]\\ \\$1
.XE
.in 3
.. 

.de HDR_5
.sp 1
.in 0 
\\n[head1]\\.\\n[head2]\\.\\n[head3]\\.\\n[head4]\\.\\n+[head5]\\ \\$1
.XS
\\n[head1]\\.\\n[head2]\\.\\n[head3]\\.\\n[head4]\\.\\n[head5]\\ \\$1
.XE
.in 3
.. 

.de HDR_6
.sp 1
.in 0 
\\n[head1]\\.\\n[head2]\\.\\n[head3]\\.\\n[head4]\\.\\n[head5]\\.\\n+[head6]\\ \\$1
.XS
\\n[head1]\\.\\n[head2]\\.\\n[head3]\\.\\n[head4]\\.\\n[head5]\\.\\n[head6]\\ \\$1
.in 3
.XE
.. 

.\"-----------------------------------------------------------------
.\" END MACRO DEFINITIONS
.\"-----------------------------------------------------------------

.pl 58
.po 0
.ll 72
.lt 72
.ds LF Day 
.ds RF FORMFEED[Page %]^
.ds CF 
.ds LH INTERNET DRAFT
.ds CH SLP Exclusion Directive
.ds RH Exp. May 2003  
.hy 0
.ad l
.in 0

   
Internet Engineering Task Force                            Michael Day
INTERNET DRAFT                                                     IBM
23 December 2002				 Expires in six months

.ce 1000
Exclusion Extension for Service Location Protocol v2
draft-day-svrloc-exclusion-03.txt
.ce 0
.sp 5

.in 0
Status of This Memo
.in 3
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.
	
.bp
.HDR_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.

.HDR_2 "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.

.HDR_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.

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. .

.HDR_2 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].

.bp
.RETURN_HDR_1 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.

.KS
.HDR_2 Exclusion\ Extension\ Fields

The Exclusion extension has the following format:
.DS L


   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) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

.DE
.KE 
.HDR_3 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
implementations

.HDR_4 Using\ the\ Size\ Field\ to\ Calculate\ Length\ of\ Entries

The size of the Exclusion Entries field MUST be calculated by
multiplying the value of the Size field by the value of the Number of
Entries field. 

.RETURN_HDR_3 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 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.

.HDR_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.

.HDR_3 Exclusion\ Interval

The Exclusion Interval indicates the lifetime, in seconds, of the
containing Exclusion Directive. The interval begins when the SA or DA
receives the Exclusion Directive. 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 satellite links. 

.HDR_3  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.

.HDR_4 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 containing 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 messages to deliver
Exclusion Directives. Dummy request messages are covered in section
3.1 below.

.RETURN_HDR_3 Authentication\ Blocks

The Number of Auth Blocks indicates how many authentication blocks
are contained in the containing Exclusion Directive. The format of the
authentication block is covered in section 4 below.

.KS
.RETURN_HDR_2 Exclusion\ Directive\ Functionality

The purpose of the Exclusion Directive is to cause SAs or DAs to
silently discard specific SLP requests that originate 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: 

.nr PI 5
.nr step 1 1
.RS
.IP \n[step]. 3
Providing a more compact mechanism to silence previous responders.
.IP \n+[step].
Magnifying the effect of the silencing mechanism by specifying a quiet interval.
.RE
.KE

.HDR_3 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 Directive).

The Exclusion Directive State Table (EDST) is the collection 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 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, process the request normally.)


.RETURN_HDR_1  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 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.

.KS
If the SA or DA supports the Exclusion Directive, it MUST perform the
following steps when processing an SLP v2 Request message.
.nr PI 5
.RS
.nr step 1 1
.IP \n[step]. 3
If the request message is unicast or if the receiving agent does not
recognize the Exclusion Directive, go to step 6 below.
.IP \n+[step].
If the incoming request does not have an Exclusion Directive,
proceed to step 6.
.IP \n+[step].
Extract the Exclusion Directive from the request. Search the
Directive's Exclusion Entries list for the receiving agent's IP
address. If not found, proceed to step 6.
.IP \n+[step].
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.)
.IP \n+[step].
Extract the source address and port from the incoming 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.
.IP \n+[step].
If the SA or DA has not discarded the request up to this point,
evaluate the request normally as outlined in [1].
.RE
.KE
.in 3

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.

Note that additional steps may be necessary if the Exclusion
directive contains one or more authentication blocks. These
steps are outlined in section 4.

.KS 
.HDR_2 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:
.nr PI 5
.RS
.nr step 1 1
.IP \n[step]. 3
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. 
.IP \n+[step].
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. 
.RE
.in 3
.sp 1
When an SA or DA receives a dummy SLP request that contains an
Exclusion Directive, the receiving agent MUST extract the Exclusion
Directive from the dummy request and ensure that the local EDST
contains a record corresponding to the Exclusion Directive. This is
described in section 3, step 4 above. 


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).
.KE 
.KS

.HDR_3 Format\ of\ Dummy\ Service\ Request
.DS L
   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)\\
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.DE
.KE
.HDR_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 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 authentication
block, the SA or DA SHOULD validate the signature of the Exclusion
Directive. Authentication of Exclusion Directives is covered in
section 4.

.KS
.HDR_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):
.nr PI 5
.RS
.nr step 1 1
.IP \n[step]. 3
Send a new Service Request with no PR list and no Exclusion Directive;
process the replies and remember the respondents as RL1. 
.IP \n+[step].
Build an exclusion list and remember it as list EL1.
.IP \n+[step].
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.
.IP \n+[step].
The intersection of EL1 and RL2 are agents that do not support the
Exclusion Directive. Create PRL1 = EL1 n RL2. Build EL2 = RL2 - PRL1.
.IP \n+[step].
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. 
.IP \n+[step].
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. 
.RE
.in 3
.sp 1
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.
.KE
.KS

.RETURN_HDR_1 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.

.HDR_2 The\ Exclusion\ Directive\ Authentication\ Block

The format of the Exclusion Directive Authentication Block is the same
as that used by SLP v2 [1].

.DS L
   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...            \\
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.DE
.KE
.KS
.HDR_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:
.nr PI 5
.RS
.IP \[bu] 3 
16-bit Exclusion XID
.IP \[bu] 
32-bit Nonce
.IP \[bu] 
16-bit Exclusion Interval
.IP \[bu] 
8-bit Exclusion Entry size
.IP \[bu] 
16-bit Number of Entries
.IP \[bu] 
Variable-length Exclusion Entries.
.RE
.KE

.RETURN_HDR_1 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 generation and
validation, each signed Exclusion Directive can be cryptographically
unique. Unsigned Exclusion Directives can also be cryptographically
unique but their source can be spoofed.

.KS
By using the nonce correctly, Exclusion Directives can be specific
to:
.nr PI 5
.RS
.nr step 1 1
.IP \n[step]. 3
The source address and port of the requesting UA.
.IP \n+[step].
The XID of the request.
.IP \n+[step].
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.  
.RE 
.KE 

.HDR_2 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 appropriate algorithm to generate a
nonce with the requisite random characteristics. 

.KS
For each Exclusion Directive:
.nr PI 5
.RS
.nr step 1 1
.IP \n[step]. 3
Generate a random 128-bit integer to use as the nonce.
.IP \n+[step].
Initialize an Exclusion Directive, including the XID of the
request that is subject to response suppression.
.IP \n+[step].
Insert the nonce value from (1) into the Exclusion Directive.
.IP \n+[step].
Optionally sign the Exclusion Directive as outlined in the section on
Authentication above. 
.IP \n+[step].
Use a Exclusion Directive containing the nonce in all
requests and dummy Service Requests for the XID in step (2).
.IP \n+[step].
IMPORTANT - use a DIFFERENT, cryptographically generated nonce
for each request XID for which you are issuing an Exclusion
directive.
.RE
.KE
.KS
.HDR_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 evaluate Exclusion Directives
in request messages. 

.HDR_3 Zero-filled\ Nonce

UAs that don't have the ability to generate 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).

.RETURN_HDR_2 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 Directive, 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 Exclusion 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 random value. Also, the nonce is large enough to make
guessing its value in the next request too difficult for the attacker.
.KE
.RETURN_HDR_1 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 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 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 MUST  be cryptographically unique and
random values if they are to provide any safeguard against a replay
attack.

.HDR_1 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
recommended some important changes during the review process.
.KS
.HDR_1 References
.nr PI 5
.RS
.nr step 1 1
.IP \n[step]. 3 
Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service
Location Protocol Version 2", RFC 2608, June 1999.
.IP \n+[step].
Bradner, S,. "Key Words for Use in RFCs to Indicate Requirements
Levels", BCP 14, RFC 2119, March 1997
.RE
.KE
.KS
.HDR_1 Author's\ Contact\ Information

Michael Day
IBM
3039 Cornwallis Road
Research Triangle Park, NC 27709

Phone:  919 543-4283

Email:  mdday@us.ibm.com
.KE
.KS
.HDR_1 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,
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."
.KE

.TC