Internet Engineering Task Force                               C. Perkins
INTERNET DRAFT                                                E. Guttman
                                                        Sun Microsystems
                                                        09
                                                        14 October  1998

               DHCP Options for Service Location Protocol
                       draft-ietf-dhc-slp-04.txt
                       draft-ietf-dhc-slp-05.txt

Status of This Memo

   This document is a submission by the Dynamic Host Configuration
   Working Group of the Internet Engineering Task Force (IETF).
   Comments should be submitted to the dhcp-v4@bucknell.edu mailing
   list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  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.''

   To view the entire list of current Internet-Drafts, please check
   the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

Abstract

   The Dynamic Host Configuration Protocol provides a framework for
   passing configuration information to hosts on a TCP/IP network.
   Entities using the Service Location Protocol need to find out the
   address of Directory Agents in order to transact messages.  Another
   option provides an assignment of scope for configuration of SLP User
   and Service Agents.

1. Introduction

   The Dynamic Host Configuration Protocol [3] [4] provides a framework
   for passing configuration information to hosts on a TCP/IP network.
   Entities using the Service Location Protocol, Version 2 [4] [6] need to
   obtain the address of Directory Agents and Scope configuration.  The
   Service Location Protocol (SLP) provides a default configuration
   for Scopes and Directory Agents may be discovered using multicast
   or broadcast.  It is useful in a larger deployment to be able
   to configure SLP Agents using DHCP, so as to centralize the
   administration and to deploy SLP in networks where multicast routing
   is not available.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [1]. [2].

2. Introduction

   The DHCP options described below are used to configure Agents using
   the Service Location Protocol, Version 2. 2 [6].

   The SLP Directory Agent option is used to configure User Agents and
   Service Agents with the location of Directory Agents in the network.
   These Directory Agents are assumed to support all of the scopes
   supplied by the SLP Scope Option.

   If the SLP Scope Option is absent, the scope string "default" is
   used instead.  If there is a scope string configured using local
   configuration on the host that is used if no

   The SLP Scope Option has
   been sent.  DHCP configuration takes precedence over the local both default and static
   scope configuration of SLP scope lists.  SLP Agents (be they Directory
   Agents, User Agents or Service Agents) which use the SLP Directory
   Agent Option MUST be configured with a scope. agents.

3. SLP Directory Agent Option

   This option specifies the location of one or more SLP Directory
   Agents.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Code = 78   |    Length     |       a1      |      a2       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      a3       |       a4      |       a1      |      ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The SLP Directory Agent Option specifies a list of IP addresses
   for Directory Agents.  Directory Agents MUST be listed in order of
   preference, if there is an order of preference.

   The address of the Directory Agent is given in network byte order.
   The length of the option MUST always be divisible by 4 and has a
   minimum length of 4.

   The Directory Agents listed in this option MUST be configured with
   the a non-empty subset of the scope list that the Agent receiving the
   Directory Agent Option is configured with.  See the notes below.

   SLPv2 Service Agents which are configured using the SLP Directory
   Agent Option MUST send a SrvRqst to the DAs in the DHCPOFFER. This
   SLPv2 SrvRqst sets the Scope List to the value configured by the SLP
   Scope Option if one was sent or "DEFAULT" otherwise.

   The service
   type for the request is "service:directory-agent" and the predicate
   is omitted.  The reply will include the DA's attributes, scope list.

   The SA MUST register all service with the DA which it advertises
   which are advertised in one or more of the scopes in the DA's scope
   list.  The SA MUST register no faster than the "min-lifetime" and not
   slower than the "max-lifetime" attributes of the DA. These attributes
   are obtained in the DAAdvert solicited by the SA after it receives
   the SLP Directory Agent Option DHCPOFFER. SLPv2 User Agents which are configured using the SLP Directory Agent
   Option MUST send their requests specification [6] defines how to the DAs listed, using the entire
   list of scopes they are configured with. use this option.

4. SLP Service Scope Option

   The scope list is a comma delimited list which indicates the scopes
   that a SLP Agent is configured to use.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Code = 79   |    Length     |  <Typed Scope   <Scope List> String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Length indicates the number of bytes which follow.  Since the
   Scope-List String is encoded using UTF8 characters, it may be the
   cast that the Length is not the same as the number of characters in
   the Scope-List String.

   The minimum length is 0, and the maximum length is 256.  This imposes
   a limit on the size of the Scope-List String which can be delivered
   which does not exist in SLP. DHCP administrators will therefore have
   to be careful to not configure very long scope names or very long
   lists of scopes for any Agents in their network.

   The Typed Scope List includes a list of scopes for the SLP Agent.
   The list may be a list of scopes, such as "north,south,east,west".

   The list may also include items which are 'typed scopes.'  These
   items indicate that SAs MUST advertise particular service types in
   a scope other than that given in the scope list.  UAs MUST issue
   requests for services of these types in the scopes listed, or some
   subset of the scopes.  DAs ignore typed scopes in the SLP Service
   Scope Option.

   For example, "default,(service:printer:lpr=Math Department)"
   indicates that SAs advertise all services in scope default except
   for lpr printers, which are advertised in the Math Department scope.
   UAs will request all services using the "default" scope, except lpr
   printers, which String syntax and usage are advertised in the "Math Department" scope.  DAs
   will simply be configured defined in the scope "default" since they ignore
   the typed scope argument.

   The grammar for the typed scope list is:

     ts-list    = ts-item / ts-item `,' ts-list
     ts-item    = scope-list / `(' srv-type `=' scope-list `)'
     srv-type   = ALPHA *srv-safe [ `.' 1*srv-safe ]
     srv-safe   = ALPHA / DIGIT / `+' / `-'
     scope-list = scope-item / scope-item "," scope-list
     scope-item = 1*safe-scope
     safe-scope = ; Any character except rsvd-scope.
                  ; Reserved characters must be escaped.
     rsvd-scope = `(' / `)' / `,' / `\' / `!'  / `<' / `=' / `>' / `~'
                  CTL / `;' / `*' / `+'
     escaped    = `$\backslash$' HEXDIGIT HEXDIGIT

   This grammar follows ABNF rules [2].  Reserved characters used in
   scope names must be escaped.  Reserved characters in <srv-type> names
   are not allowed.  Note that <srv-type> names may include a Naming
   Authority extension. SLPv2
   specification [6].

4.1. Zero Length Scope-List String Configuration

   A SLP Service Scope Option which indicates a Length of 0 configures
   the SLP Agent to use "User Selectable Scopes".

   If this is done, the SLP Agent MUST NOT be configured using the SLP
   Directory Agent Option.

   Instead, the SLP Agent will discover scopes using Directory Agent
   discovery (or Service Agent Discovery) as defined in  [4].

   The SLP Agent will then use the aggregation aggregated list of scopes of all known
   DAs.  If no DAs are known, the UA will use SA discovery to determine
   the list of scopes it
   discovers on the network to configure its own scope list. network, as defined in  [6].

   Note that this configuration is tantamount to removing all
   centralized control of the scope configuration of hosts on the
   network.  This makes it possible for every User Agent to see every
   service.  This may not be desirable as users may not be able to or
   desire to decide which services are appropriate for them.

5. Security Considerations

   If a malicious host is able to insert fraudulent information in
   DHCPOFFER packets sent to a prospective SLP Agent then the SLP Agent
   will be unable to obtain service, or may unwittingly be directed to
   use the incorrect services.

   Many opportunities for denial of service exist.  A service agent
   could find that it might rely on fraudulent or otherwise malicious
   directory agents to advertise its services.  DHCPOFFERs could prevent
   the regular SLP framework from functioning by directing clients to
   not use multicast, to use nonexistent directory agents and so on.

   These difficulties are inherited from the much larger and more
   serious problem, viz.  securing or authenticating any information
   whatsoever from a DHCP server (or client!)  is not possible in common
   DHCP deployments.

References

   [1] T. Berners-Lee, R. Fielding, and L. Masinter.  Uniform Resource
       Identifiers (URI): Generic Syntax.  RFC 2396, August 1998.

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

   [2] D. Crocker

   [3] B. Carpenter and P. Overell.  Augmented BNF for Syntax
       Specifications:  ABNF. Y. Rekhter.  Renumbering needs work.  RFC 2234, November 1997.

   [3] 1900,
       February 1996.

   [4] R. Droms.  Dynamic Host Configuration Protocol.  RFC 2131, March
       1997.

   [4]

   [5] E. Guttman, C. Perkins, and J. Kempf.  Service Templates and
       service:  Schemes.  draft-ietf-svrloc-service-scheme-11.txt,
       October 1998.  (work in progress).

   [6] E. Guttman, C. Perkins, J. Veizades, and M. Day.  Service
       Location Protocol version 2.  draft-ietf-svrloc-protocol-v2-04.txt,
       March  draft-ietf-svrloc-protocol-v2-09.txT,
       October 1998.  (work in progress).

   [7] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan.  Service
       Location Protocol.  RFC 2165, July 1997.

   [8] F. Yergeau.  UTF-8, a transformation format of unicode and ISO
       10646.  RFC 2279, October 1998.

   [9] D. Crocker and P. Overell.  Augmented BNF for Syntax
       Specifications:  ABNF.  RFC 2234, November 1997.

Author's Address

   Questions about this memo can be directed to:

  Charles E. Perkins                       Erik Guttman
  Technology Development Group             Technology Development Group
  Mail Stop MPK15-214                      Mail Stop UFRA02
  Sun Microsystems, Inc.                   Sun Microsystems, Inc. Inc..
  15 Network Circle                        Bahnstr. 2
  Menlo Park, CA  94025                    74915 Waibstadt, Germany
  phone: +1 650-786-6464            phone: +49 7263 911 701
  fax:   +1 650-786-6445               or:  +1 650 786 5992
  email: Charles.Perkins@Sun.Com           Erik.Guttman@Sun.Com
  Web: http://www.svrloc.org/~charliep