NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
John Veizades <veizades@home.net>
Erik Guttman <erik.guttman@eng.sun.com>
Frank Kastenholz <kasten@ftp.com>
Jeffrey Burgan <jburgan@baynetworks.com>
General Discussion:srvloc@corp.home.net
To Subscribe: srvloc-request@corp.home.net
Archive:
The Service Location Protocol Working Group is chartered to make the discovery and use of Internet services an easier task than allowed by current practice.
Using the Service Location Protocol this working group will work on making additions to this work to extend this functionality to the Internet at large.
This working group will also work on defining service schemes and evaluate scheme presented by contributors outside of the IETF.
Goals and Milestones:
· Finding Stuff (How to discover services)
· Service Location Modifications for IPv6
· Advertising Services (Providing information to support service discovery)
· Defining White Pages and Yellow Pages Services
· Service Specific Multicast Address Assignment for use with the Service Location Protocol
Minutes of the Service Location Protocol (SVRLOC) Working Group
Reported by: Charlie Perkins and Erik Guttman
25 Service Location Protocol Last Call
- 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
- Rewording the portions on digital signatures and certificates (no longer dependent on RSA or X.509)
- draft-ietf-svrloc-advertising-00.txt
- draft-ietf-svrloc-discovery-00.txt
- draft-ietf-svrloc-wpyp-00.txt
10 Discuss Working Group Charter - Plans
II. Discussion on changes to the SLP during the IESG Working Group Last Call
The authentication mechanism for SLP was presented to those who were unfamiliar with the recent revisions to the draft.
Assigning an SLP Scope called a "Protected Scope" does Service authentication. 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
(|*|) Directory Agent Public Key for the Scope
| +-> 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 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 want to propose something that is very simple and can 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 insufficient 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 presence of authenticated URL or ATTRs in the SLP message.
III. 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 three.
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.
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.
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 fields 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 Working Group last call in May.
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 that 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 seems 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.
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 Working Group. Hopefully, this work will be completed by the 39th IETF, so that all drafts can be submitted to the IESG for review and possible publication as RFCs.
We recommend that 'finding stuff' go to BCP, and 'discovery' go to Experimental.
This needs a little more work and can go to Informational.
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.
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.
This will go to Working Group 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.
SLP used to populate LDAP dynamically:
SLP could be used to dynamically 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 Working Group.
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