Internet Engineering Task Froce                            Erik Guttman
INTERNET DRAFT                                         Sun Microsystems
9 March 1999
Expires in six months

       Vendor Extensions for Service Location Protocol, Version 2
                 draft-guttman-svrloc-vendor-ext-01.txt

Status of this Memo

   This document is an individual contribution for consideration by
   the Internet Engineering Task Force.  Comments should be submitted
   to the svrloc@svrloc.org mailing list.  This document is intended
   to be submitted to the IESG for consideration as an Informational
   RFC.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   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/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at:

      http://www.ietf.org/shadow.html.

   Copyright   (C) The Internet Society 1999.  All Rights Reserved.


Abstract

   The Service Location Protocol, Version 2 [1] contains a number of
   features which are left up to vendors.  This document describes how
   each of these features can be used safely (with no possibility of
   name collisions).  This document also describes how vendors can
   extend the protocol safely without requiring any IETF standardization
   work.  Finally, this document defines a new extension to the SLPv2:
   The Vendor Opaque extension.




E. Guttman             Expires: 9 September 2000                [Page 1]


Internet Draft        Vendor Extensions for SLPv2             March 2000


   Table of Contents

      1.0   Introduction . . . . . . . . . . . . . . . . . . . . .  2

            1.1   Terminology  . . . . . . . . . . . . . . . . . .  2

      2.0   Enterprise Numbers . . . . . . . . . . . . . . . . . .  3

      3.0   Naming Authorities . . . . . . . . . . . . . . . . . .  3

      4.0   Vendor Defined Attributes  . . . . . . . . . . . . . .  4

      5.0   Vendor Opaque Extension  . . . . . . . . . . . . . . .  5

            5.1 Vendor Opaque Extension Format . . . . . . . . . .  6

            5.2 Example: Acme Extension for UA Authentication  . .  6

      6.0   Extensions Requiring IETF Action . . . . . . . . . . .  7

      7.0   IANA Considerations  . . . . . . . . . . . . . . . . .  8

      8.0   Security Considerations  . . . . . . . . . . . . . . .  8


      References . . . . . . . . . . . . . . . . . . . . . . . . .  8

      Author's Address . . . . . . . . . . . . . . . . . . . . . .  9

1.0 Introduction

   The Service Location Protocol, Version 2 [1] defines a number of
   features which are extensible.  This document clarifies exactly
   which mechanisms can be used to that end (Sections 3-5) and which
   cannot (Section 6).  Conventions are specified which ensure that
   the protocol extension mechanisms in the SLPv2 specification will
   not possibly have ambiguous interpretations.

   This specification introduces only one new protocol element, the
   Vendor Opaque Extension.  This Extension makes it possible for a
   vendor to extend SLP without having to engage in any standardization
   efforts or bureaucratic activity whatsoever once the vendor has
   registered itself with IANA and obtained an Enterprise Number.

1.1 Terminology

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [2].

   Service Location Protocol terminology is defined in [1]. IANA



E. Guttman             Expires: 9 September 2000                [Page 2]


Internet Draft        Vendor Extensions for SLPv2             March 2000


   registration terminology is defined in [6].

2.0 Enterprise Number

   Enterprise Numbers are used to distinguish different vendors in IETF
   protocols.  Vendor Extensions to SLPv2 SHOULD use these values to
   avoid any possibility of a name space collision.  Each vendor is
   responsible for ensuring that vendor extensions under their own
   authority are non-conflicting.

   RFC 1700 lists the Enterprise Numbers registered at the time of
   publication as well as rules on how to register new numbers:

      To request an assignment of an Enterprise Number send the
      complete company name, address, and phone number; and the
      contact's person complete name, address, phone number, and
      email mailbox in an email message to <iana-mib@isi.edu>. [3]

   The complete up-to-date list is maintained by IANA [4].

   All a Vendor must do is register their Vendor ID and they are then
   able to extend SLPv2 in many ways without requiring any additional
   interaction with any standards organization.

3.0 Naming Authorities

   Naming Authorities are defined by SLPv2 [1] as an agency or group
   which catalogues Service Types and attributes.

   A Service Type is a string representing a service which can
   be discovered by SLPv2.  Attributes may be associated
   with a particular Service Type which is advertised by SLPv2.

   Service Type strings and service attributes may be registered with
   IANA by creating a Service Template [5].  The template is included
   in an internet draft and an email message is sent to
   srvloc-list@iana.org requesting that the template be included in
   the Service Template registry.  In this case the naming authority
   for the service type is IANA.

   It is also possible for a Vendor to create their own naming
   authority.  In this case, any service type or attributes may be used.
   SLPv2 allows arbitrary naming authorities to coexist.  To use an
   explicit naming authority, a vendor simply employs their Enterprise
   Number as a naming authority.  For example, for the following
   (fictitious) Enterprise Number

     9999  Acme, Inc.                      Erik Guttman  femur@neato.org

   the Naming Authority string to use would be "9999".  A service: URL
   which used this Naming Authority to advertise a Roadrunner Detector



E. Guttman             Expires: 9 September 2000                [Page 3]


Internet Draft        Vendor Extensions for SLPv2             March 2000


   service could look like

      service:roadrunner-detector.9999://neato.org:9341

   Service types which are defined under a naming authority based on an
   Enterprise Number are guaranteed not to conflict with other service
   type strings which mean something entirely different.  That is also
   true of attributes defined for service types defined under a naming
   authority.

   To create a safe naming authority with no possibility of name
   collisions, a vendor SHOULD use their Enterprise Number as a
   naming authority.

4.0 Vendor Defined Attributes

   SLPv2 [1] suggests that

      Non-standard attribute names SHOULD begin with "x-",
      because no standard attribute name will ever have those
      initial characters.

   It is possible that two non-standard attributes will conflict that
   both use the "x-" prefix notation.  For that reason, vendors SHOULD
   use "x-" followed by their Enterprise Number followed by a "-" to
   guarantee that the non-standard attribute name's interpretation is
   not ambiguous.

   For example, Acme, Inc.'s Enterprise Number is 9999.  Say the
   Service Template for NetHive (a fictitious game) was:

     ------------------------------------------------------------
     template-type=NetHive

     template-version=1.0

     template-description=
       The popular NetHive game.

     template-url-syntax=
       url-path = ; There is no path for a NetHive service URL.

     features= string M O
     # The list of optional features the NetHive server supports.
     secure session, fast mode

     current-users= string M
     # The list of users currently playing
     ------------------------------------------------------------

   Acme's server advertises a feature which is not on the list



E. Guttman             Expires: 9 September 2000                [Page 4]


Internet Draft        Vendor Extensions for SLPv2             March 2000


   of standard features, "x-9999-cheat-mode".  Only an Acme
   client would request this attribute to discover servers,
   since it is not standard.

5.0 Vendor Opaque Extension

   SLPv2 [1] defines a protocol extensibility mechanism.  SLPv2
   Extensions are added at the end of a message and have 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          |       Next Extension Offset   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Offset, contd.|                Extension Data                 /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The format of the Extension Data depends on the Extension ID.  Refer
   to [6] for a full description of different mechanisms available for
   registration of values with IANA.

     Extension ID Range   Assignment By      Protocol Action

       0x0000 - 0x3FFF    Designated Expert  Ignore Extension if
                                             Extension ID
                                             unrecognized

       0x4000 - 0x7FFF    Designated Expert  Drop message if
                                             Extension ID
                                             unrecognized

       0x8000 - 0x8FFF    (No one!)          Ignore Extension if
                                             Extension ID
                                             unrecognized

       0x9000 - 0xFFFF    (No one!)          Reserved.

   Vendors may extend SLPv2 in any of three ways.  First, they may
   define a new extension to SLPv2 in an internet draft.  The vendor
   then requests that the IESG contact the designated expert for SLP
   who will review the document.  If the document is sound, the
   document will be published as an Informational RFC with the new
   Extension ID assigned.

   An experimental extension may be done using the range 0x8000 to
   0x8FFF.  There is always the risk, however, that another vendor
   will use the same ID, since these IDs are not registered.

   Finally, the following OPTIONAL to implement extension allows a
   Vendor to define their own extensions which are guaranteed to have



E. Guttman             Expires: 9 September 2000                [Page 5]


Internet Draft        Vendor Extensions for SLPv2             March 2000


   a unique interpretation.


5.1. Vendor Opaque Extension 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 = <TBD>      |       Next Extension Offset   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Offset, contd.|               Enterprise Number               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Ent. #, contd.|                Extension Data                 /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Enterprise Number is included in the Extension as a 4 byte
   unsigned integer value.  The Extension Data following is guaranteed
   to have an unambiguous interpretation determined by the vendor.


5.2 Example: Acme Extension for UA Authentication

   For example, the Acme Corporation, whose Enterprise Number is 9999,
   can define three extensions to SLP to create an application level
   access control to service information.  (Note that the first byte in
   the Extension Data is used to differentiate the different extensions
   under the authority of the vendor.)

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Client ID = 1 |       Client ID Length        |   Client ID   /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Acme UA multicasts a SLP request includes the Vendor Opaque
   Extension, with the Enterprise Number set to 9999 and the Extension
   Data as above.  The Client ID is a string formatted in the Acme
   Client ID format (not described here).

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Challenge = 2 |        Challenge Length        |Challenge data /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   An Acme SA which receives a SLP request for 'restricted services'
   will ignore it unless the request includes a Vendor Opaque Extension
   with an Acme Client ID.  In that case it sends a reply to the
   requesting UA with zero results and a Vendor Opaque Extension with
   the Enterprise ID set to 9999 and containing the above "Challenge"
   data in the Extension Data.  The challenge is in the Acme Challenge
   format (not described here).


E. Guttman             Expires: 9 September 2000                [Page 6]


Internet Draft        Vendor Extensions for SLPv2             March 2000

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Response = 3 |        Response Length         |   Response    /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   An Acme UA which receives a reply with zero results and a Vendor
   Opaque Extension with a "challenge", as above, may unicast a request
   to the SA which sent the challenge.  The request will be the same as
   the initial one (which contained the "Client ID" Acme vendor
   extension), however in this case it will include a Vendor Opaque
   extension with the Enterprise Number set to 9999 and the Extension
   data including the "Response" data as above.  The "Response" data is
   in the Acme format (not described here).

   The SA will then process the response and if the UA has
   authenticated itself, the SA will uncast a reply including the
   requested information.

6.0 Extensions Requiring IETF Action

   Terminology and procedures for IETF Actions related to registration
   of IDs with IANA are defined in [6].

   SLPv2 [1] defines a number of features whose modification cannot
   be done by simple vendor extension.  These include:

   - Block Structure Descriptors (BSD) identifies the format
        of the Authenticator in the Authentication Block included
        in some SLP messages.  BSD values from 0x0003-0x7FFF are
        assigned by IETF Consensus.

   - New function-IDs in the range 12-255 are standardized
        by the method of IETF Consensus.

   - New error numbers in the range 15-65535 are assigned on
        the basis of a Standards Action.

   - New SLP Extensions with types in the range 2-65535 are
        registered following the review of the Designated Expert.

   - New Service Types are defined and registered with IANA
        following the review of the Designated Expert.  See [5].

   Only changes to the base "required to implement" protocol require
   IETF Consensus.  Extensions are all defined to be done using the
   approval of a Designated Expert, though in some cases this involves
   publishing an Informational RFC.


E. Guttman             Expires: 9 September 2000                [Page 7]


Internet Draft        Vendor Extensions for SLPv2             March 2000


7.0 IANA Considerations

   This document discusses vendor extensibility to SLPv2 but does not
   introduce any new number or name spaces which need to be administered
   by IANA.  The techniques described in this document make it possible
   for vendors to extend SLPv2 by doing nothing more than registering
   an Enterprise Number with IANA (as described in RFC 1700 [4]).


8.0 Security Considerations

   Vendor extensions may introduce additional security considerations
   into SLP.

   This memo describes mechanisms which are standardized elsewhere
   [1] [3] [5].  The only protocol mechanism described in this document
   (see Section 5 above) is no less secure than 'private use' extensions
   defined in SLPv2 [1].

   The example in Section 5.2 above shows how Vendor Opaque Extensions
   can be used to include a challenge response mechanism to SLP so that
   SAs can enforce an access control policy using a cryptographicly
   secure authentication mechanism.  This is merely an example and
   protocol details were intentionally not provided.  A vendor could,
   however, create a mechanism similar to this one and provide
   additional security services to SLPv2 in the manner indicated in the
   example.


References

   [1] Guttman, E., Perkins, C., Veizades, J., Day, M., "Service
           Location Protocol, Version 2", RFC 2608, July 1999.

   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
           Levels", BCP 14, RFC 2119, March 1997.

   [3] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700, October
           1994.

   [4] ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers

   [5] Guttman, E., Perkins, C., Kempf, J., "Service Templates and
           URLs", RFC 2609, July 1999.

   [6] Narten, T. and H. Alvestrand, "Guidelines for Writing
           an IANA Considerations Section in RFCs, BCP 26, RFC 2434,
           October 1998.






E. Guttman             Expires: 9 September 2000                [Page 8]


Internet Draft        Vendor Extensions for SLPv2             March 2000


Author's Address

               Erik Guttman
               Sun Labs, Network and Security Center
               Sun Microsystems
               Eichhoelzelstr. 7
               74915 Waibstadt
               Germany

   Phone:     +49 7263 911 701
   Messages:  + 1 650 786 5992
   Email:      erik.guttman@sun.com










































E. Guttman             Expires: 9 September 2000                [Page 9]