Editor's Note: These minutes have not been edited.
SVRLOC WG Meeting minutes
38'th IETF - Memphis, Tennessee
Minutes taken by Charlie Perkins and by Erik Guttman.
Agenda
MINS TOPIC
5 Agenda
25 Service Location Protocol Last Call
Changes in draft 15 to 16
- Authentication Support
- Modification of String Search Semantics
- Definition of Service Specific Multicast Address
assignment from a string hash on the Service Type
String
- Dialect header field is reserved now.
Changes in draft 16 to 17
- Rewording the portions on digital signatures and
certificates (no longer dependent on RSA or X.509).
20 Discuss Ryan Moats' drafts
- draft-ietf-svrloc-advertising-00.txt
- draft-ietf-svrloc-discovery-00.txt
- draft-ietf-svrloc-wpyp-00.txt
10 Discuss HOPS
10 Discuss WG Charter - Plans
Discussion on changes to the SLP during the IESG WG Last Call
The authentication mechanism for SLP was presented to those
who were unfamiliar with the recent revisions to the draft.
Service authentication is done by assigning a SLP Scope called
a "Protected Scope". The SA signs the attributes and url of a
service advertisement in a Protected Scope. The UA then checks
the signature on the URL and/or attributes of a service in order
to validate the service. The following illustration shows the
relationship of SA, UA and DA in this process:
Service Protected Scope operations require
|
+---< Signed URL Private Key for the Scope
| +-< Signed Attributes
| |
| |
| |
(|*|) Directory Agent Public Key for the Scope
| |
| |
| | Application
| | |
| +-> User Agent Public Key for the Scope
+--->
The DA does not *alter* the signed URL or its signature, or
the attributes or their signature; it merely caches them.
The DA uses the same algorithm as the UA to determine if the
registration is valid. It will reject URLs or Attributes
that are registered or deregistered if the signature does
not check out using the signature checking algorithm.
The UA obtains a signed URL by doing a Service Request in
a Protected Scope. The UA may obtain a signed set of
attributes by doing an attribute request in a Protected
Scope. This attribute request supplies the URL of a
service in the Protected Scope (as when it has already
been obtained with a Service Request.) This is a way of
obtaining all of the attributes of a particular service
in such a way as to be able to be sure the attributes
are authentic.
Signatures are calculated over the registered string, its
character type, a time-stamp, and the 'lifetime'. This will
prevent their illegitimate use for replay attacks. Further,
the UA and DA may only check the signature. They may not
register the same or modified services elsewhere.
The distribution of Keys is required to use generate signed
service advertisements and to verify signed URLs or
attributes. The mechanism for this key distribution is not
specified by SLP. DHCP similarly does not define key
distribution for its authentication mechanism.
A Certificate format is provided to facilitate key
distribution. This format is *not* required but may be
useful. It provides a binding of Protected Scope string
to a scopes public key, along with a duration of validity
for the certificate.
*** It was brought up in the meeting that we should/could
use X.509 certificates. These have a lot of thought put
into them, and include many important fields. Our
response was that one *could* use them - we just wanted
to propose something that was very simple and could be
transcribed in a mail-safe format. It was emphasized
that the SLP certificate format is only a *MAY*.
*** In particular, there is no provision for the name of
the Certificate Authority in the certificate. This
may prove insufficiant and require revision in the
future, if this certificate format is used.
*** Question: Could SASL be used? This is a way of using
a more general authentication mechanism.
Answer: SASL is connection oriented. SLP is not
connection oriented, so SASL is unsuitable.
There are two bits in the header which indicate the
presense of authenticated URL or ATTRs in the SLP message.
Ryan Moats' Drafts - discussion
(Ryan's slides are included - in postscript format)
One draft, by Ryan Moats, Martin Hamilton from work by
Russ Wright, has been split into 3.
Finding Stuff "-discovery-00.txt"
This draft describes a mechanism for discovery of
services across the Internet. The first recourse
should be to look for a SRV record in the DNS.
The second, is to look for a 'common alias' for
a service in the DNS. If these fail, look for
Service URLs in the DNS.
The last case may indicate a SLP Directory Agent.
This DA may be used to locate services by attribute.
This final bit of information is currently not in the
draft and was requested in the next version.
To "Best Current Practice"?
Advertising Services "-advertising-00.txt"
This draft describes how to bind service urls into
DNS RRs. A service type in a domain may return a
URL. It may be possible that SINK or NAPTR RRs will
be sufficient. For now, the proposal is to use TEXT
RRs as netfind did. Note that SRV RRs do not have
the right structure to allow this.
To Experimental.
Service Scheme for WP and YP services "-wpyp-00.txt"
These service types define mechanisms for obtaining
wp or yp services. Maybe HTTP should be added?
A clarification was made in the meeting: The title
and language field are used to define the language
of the template. It should be mentioned in the
service: URL document that there may be a 'default'
language.
To join other service type definitions.
Can these documents be advanced to last call?
Yes: we think we should go to WG last call in May.
HOPS presentation
This is a suggested protocol for determining Host Proximity.
It is presently exploratory - there have been no decisions
made yet. There is a white paper at http://www.ingrid.org/hops/wp.html.
There was a HOPS BOF held at the 38'th IETF - please refer to
its minutes for the results. It was plugged at the SLP meeting.
The idea which distinguishes it from SONAR and traceroute based
schemes is that it allows a third party to do the work - the
distance may be measured from the source or the target. A HOPS
server does the work using routing information and/or traceroute
somehow. The metrics are 'proximity' but not necessarily only
number of traversed routers... It seemed other metrics might
enter in.
The relation to SLP is that one might find services by 'hops
groups' (essentially a service type enumeration) - which will
presumably return a list of services ordered by hops distance.
Note that this is a service by type, not by attribute, so the
semantics are much weaker than SLP provides. It might be useful
to use HOPS to locate SLP DAs so that 'local' services may be
discovered by using SLP after determining what 'local' is, using
HOPS.
Charter discussion
Todd Rupper will look into defining IPX address specifications.
If he does, this can be added to the service: URL specification.
We anticipate we will have SLP promoted to Proposed Standard
in the month of May. There are some additional work items that
are well under way in the WG. This work will be completed by
the 39'th IETF, hopefully, so that all drafts can be submitted
to the IESG for review and possible publication as RFCs.
Ryan's drafts: 6/97
We recommend that 'finding stuff' go to BCP,
and 'discovery' go to Experimental.
API spec: 6/97
This needs a little more work and can go to Informational.
service: URL Scheme: 8/97
This needs some more work, and should be considered as a
proposed standard. Some of the work done here will be to
assess the URL scheme given the criteria in the URL scheme
acceptance process document (now in draft form.) A formal
process for registration of new service type templates will
be provided.
service types catalog: 8/97
The examples from the service URL draft will be removed
and all the known types will be bundled here. This draft
will be published as an informational RFC and be used to
'seed' the IANA registry of service types.
SLP IPv6 draft: 6/97
This will go to WG last call in May (with solicitations for
comments on the IPv6 list.) If there are no objections and
SLP has gone to PS, we will submit this draft to the IESG
to go to PS.
Additional work to do:
SLP used to populate LDAP dynamicly:
SLP could be used to dynamicly populate an LDAP directory
with network service information. This possibility needs
to be considered and worked out. This may or may not need
to be done by the SVRLOC WG.
SLP deployment and implementation experience:
As there is practical experience using SLP, and we are
ready to move from Proposed to Draft Standard, additional
work will need to be done refining the RFCs produced above.
After there is deployment experience there are two interesting
enhancements to the protocol we would like to possibly
embark upon, if there is sufficient interest:
- Hierarchical scopes and DA to DA coordination for
scalability and managed redundancy
- Discovery of 'local' and 'remote' resources for
mobile hosts
Erik Guttman
SVRLOC WG Chair
eguttman@eng.sun.com