draft-day-srvloc-exclusion-02.txt

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

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