draft-day-svrloc-exclusion-03.txt

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

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

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