draft-day-svrloc-exclusion-03.nr.txt

Pegasus is an open-source implementationof the DMTF CIM and WBEM standards. It is designed to be por

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. Extract the 
nonce from the Exclusion 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
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:  [phone]

Email:  [e-mail]
.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