Minutes: Service Location Protocol Working Group (SVRLOC)
40th IETF, Washington, D.C., December 8-12, 1997
Minutes taken by "Tom Taylor" <Tom.Taylor.taylor@nt.com>
Minutes edited by "Erik Guttman" <eguttman@eng.sun.com>
The Service Location Protocol Working Group met for one session of two hours' duration. Erik Guttman chaired the meeting.
Agenda
------
The declared goal of the meeting was to wrap up current work, by achieving closure on the remaining issues. Please see the following website for
all slides presented at the meeting:
Slides presented
----------------
Basic presentation:
http://www.srvloc.org/ietf40/SVRLOC-WG-IETF-40-index.html
New scope discussion:
http://www.svrloc.org/~charliep/ietf40.html
Progress on Wide Area Service Location (WASRV) information:
http://www.cs.columbia.edu/~jdrosen/ietf_wasrv95.ppt
http://www.cs.columbia.edu/~jdrosen/ietf_wasrv.ps
http://www.cs.columbia.edu/~jdrosen/ietf_wasrv.pdf
Document Status
---------------
At last call:
draft-ietf-svrloc-discovery-05.txt (experimental track)
Agreed to last call at the meeting:
draft-ietf-svrloc-service-scheme-05.txt (standards track)
draft-ietf-svrloc-advertising-03.txt (standards track)
draft-ietf-svrloc-wpyp-02.txt (to IANA)
draft-ietf-svrloc-lpr-scheme-00 (to IANA)
Action: chair to forward notice.
Further work required:
draft-ietf-svrloc-protocol-v2-01.txt (standards track)
Aiming to move to last call in January. Target of most of the
meeting effort.
draft-ietf-svrloc-api-02.txt (information)
Also aiming for January last call.
draft-ietf-svrloc-slp-mib-02.txt
No current push to do this work.
Work of other groups:
draft-...-wasrv-01.txt
Wide-area service location. To be considered by a BOF at the next meeting.
Erik raised the question of what to do with draft-ietf-svrloc-ipv6-02.txt. Charles Perkins observed that the IPv6 group is counting on service location. The meeting agreed that this document should move to a last call, directed to the IPv6 group. The document should be classed as standards track.
Action: chair to forward notice.
Changes To Be Implemented In SLPv2
----------------------------------
Erik identified a lengthy list of action items, classed by degree of necessity.
None of these were questioned as to whether they were a good idea, though some
elicited some discussion.
Musts:
- Signatures for Directory Agent advertisements. Currently, one malicious
entity could render the protocol inoperable.
- "Fresh" bit sent by the Service Agent, not the Directory Agent. This
prevents a race condition identified at the Munich meeting.
Highly advisable:
- New version number. SLPv2 will not interoperate with the original version.
- Use UTF-8 character representations only (RFC 2044), in line with current
IESG recommendations. This greatly simplifies string handling in SLP.
- Specify language tagging per RFC 1766.
- Defeat scoping for multicast requests, to prevent invisibility. Where no
Directory Agents are present, issue service requests with the indication
that scoping should be ignored.
- Flagging (to indicate multi- versus unicast). If the Service Agent and
Directory Agent are the same process, they are unable to distinguish
multicast from unicast, since both procedures will use the same socket.
The flagging will be a protocol layering violation, but a reasonable one.
- Relax requirements to give a lighter-weight protocol. In particular,
make support of service requests and acknowledgements mandatory only
for Directory Agents.
Further ideas:
- Allow the use of any URL.
- Use LDAP query filters. These are very similar to those now used by SLP;
their adoption would promote interoperability between the protocols.
- Rework the scope rules to make them less complex while adding more features.
- Allow UDP requests to Service Agents, for peer-to-peer operations.
- Provide SLP extension options, so that further changes will be incremental
rather than requiring rework of the entire protocol.
- Provide a reserved byte for longer request lifetimes, for instance, for
wide-area service location.
SLP Authentication Issues
-------------------------
Erik identified a number of issues, looking for some sense of direction from
the meeting.
1. Should SLP certificates be dropped from the specification? Alternatives might be to accept any certificate, or to encourage X.509.
2. Directory Agent handling of signatures is brittle. The Directory Agent must store them, then forward them on demand without any changes such as reordering, case transformation, etc.
3. Private keys must be installed in multiple places, resulting in a dispersion and dilution of trust. To solve the malicious Directory Agent problem, it is necessary for Service Agents to pass private keys to the Directory Agent, but then the latter can say anything it wants about the Service Agents it is representing.
Erik proposed at this point a detailed process based on the premise that public keys now represent certificate authorities. In the new process, the User and Directory Agents obtain the public key by asking for it. It was pointed out that this process had no means of preventing revocation.
Charle Perkins suggested that extra security be designed in only where needed. In this case, the group should retain the old model.
The sense of the meeting was that it is acceptable to pass private keys to the Directory Agent.
4. MD5/RSA is currently mandatory for signatures. However, if the User or Directory Agent does not understand the selected algorithm, it cannot process the signature in order to return a NACK to say so. Some fixes were suggested to allow algorithm negotiation, but were vulnerable to man-in-the-middle attacks or unworkable due to key unavailability. The real issue is which algorithm to make mandatory to guarantee interoperability. The discussion of this issue will be taken to the list, bearing in mind the IETF guideline that encumbered technology should be avoided.
One suggestion was made which seems promising: The UA can request algorithms
be including an extension option listing algorithms by preference. The DA or
SA will respond with a reply, including an extension indicating which algorithm
was used *and* echoing the list's order. This entire reply option will be
signed so the UA can verify that the list was not reordered by a man in the
middle to put a weaker algorithm first in the list, or eliminate harder
algorithms from the negociation.
LDAP Filters
------------
Erik presented the proposal to make SLP interoperate with LDAP filters.
Advantages:
- code re-use
- simplified LDAP back-end
Implied work items:
- SLP supports a limited range of data types. An LDAP server could satisfy
an arbitrary SLP request, but not vice versa. Need an escape mechanism
in SLP. (Make it the same as LDAP instead of the current HTML-like
escape syntax.)
- Because the approximating rules from X.500 are not supported in SLP, SLP
query handling will have to be specified very carefully to provide
consistent behaviour.
Would be nice items:
- maximum and minimum requests (suggested by Jonathan Rosenberg).
Meaningful in SLP, but not in LDAP.
- best match for approximations (suggested by Dave Oran). After a brief
discussion this proposal was discarded because the capability does not
appear in LDAP and seems obscure.
A discussion ensued on whether compatibility would be with LDAPv2 or LDAPv3. LDAPv3 specifies the use of UTF-8, but is much more complicated than LDAPv2. Erik called for a volunteer to determine the scope of effort involved in using LDAPv3. Ryan Moels of AT&T volunteered.
Action: Ryan Moels to report to list.
Jim Kempf pointed out that the SLPv1 filter is inconsistent with LDAP.
The SLPv1 filter has the form:
type/scope/predicate/
However, in LDAP, scope is not an attribute:
(&(service type = st)(predicate)), where & is the scope.
But the LDAP expression poses a problem for SLPv1, because service type appears syntactically to be part of the predicate. The suggestion was made to move
the service-type item out of the predicate. No one dissented, so this will
be done for the next version of the protocol.
Service Specific Multicast Addresses
------------------------------------
SLP was not granted the requested ranged of 1024 addresses:
- multicast does not work in the way assumed by SLP;
- this would have been an excessively large consumption of a limited resource.
The suggestion was that SLP drop the multicast feature. The original
purpose of multicast was to divert unusable traffic from nodes and links.
Jonathan Rosenberg, who had indicated that a multicast mechanism similar in
some respects to the one in SLPv1 was essential for scalability at the
Munich meeting, agreed that it could be omitted in single-domain operation.
The rest of the working group agreed to its elimination.
Requested New Directory Agent Capabilities
------------------------------------------
For increased robustness, two new Directory Agent capabilities were proposed:
- Directory Agent able to send a message that it is about to terminate.
- Directory Agent able to signal that it is congested, so that Service Agents
should back off.
A question was raised, whether the first capability implied that User and
Service Agents must now track the list of active Directory Agents. In Erik's
view, this would be optional.
Clearly, Service Agents would have to keep track of those Directory Agents
reporting congestion. This implies the need for a back-off algorithm in the
specification. Microsoft may post one to the list. It was noted that back-off
requests must be signed.
Scopes
------
Charles Perkins gave a presentation on normalized scopes for SLP.
Design premises:
- Scopes are sets of <<services>>.
- Users typically select services by <<attribute>>, not by <<scope>>. (Scope
is not an attribute.)
- Users can be assigned scopes by the administrator, to segregate access
patterns conveniently.
- Scopes are not an access control mechanism.
- <<Local scope>> defines a set of services that depends on the user, and
needs interpretation by the Directory Agent.
- Initial deployments won't use scope (services are unscoped).
This last implies a need for smooth transition into scoped administration:
User Agents assigned scopes should still be able to use existing unscoped
services.
Comment from the audience: Appletalk supplies a precedent. Users supply
scopes interactively. John Veizades noted that as a matter of history, SLP
was originally conceived of to replace NBP on Appletalk. A further comment
was made that users don't necessarily like Appletalk zones.
Charlie's specific proposal was that scopes be used as an administrative tool.
Erik emphasized that this would represent a major change in point of view from
SLPv1. Scope would not be an attribute, and would not be visible to the user.
Charles presented a picture:
scoped
UA ---------> SA
DA DA
Unscoped Scoped
The User Agent cannot currently make a scoped request to the Service Agent
because it doesn't know which scopes the Service Agent recognizes. With the
proposed changes, the User Agent can make scoped, unscoped, or ignore-scope
requests to the Service agent. Similarly, the User Agent can make unscoped,
scope 'X' plus unscoped, or scope 'X' only requests to the Directory Agent.
The middle category (scope 'X' plus unscoped) is for transition.
In the proposed scheme, the Directory Agent advertises its ability to handle
scoped queries. DHCP has to be fixed to carry the same information.
There are some potential problems with scope name collision when organizations
merge.
John ---- asked whether the user would be able to see Service Agents in other
scopes. The answer is Yes. It can either ignore scopes (thus including all
SAs in the potential list of responders) or know the scope to use a priori -
such as via DHCP.
Wide Area Service Location (WASRV)
----------------------------------
Wide Area Service Location: BOF scheduled for March. 01 draft released.
An architecture is proposed in this draft.
The mailing list is available for discussion:
to post: wasrv@lists.research.bell-labs.com
to join: un/subscribe on wasrv-request@lists.research.bell-labs.com.
The architecture has come a long way since the discussion in Munich.
Those who follow SVRLOC are encouraged to follow this work as it builds
upon the mechanisms of SLP, taking advantage of scalable wide area
multicast protocol techniques.
Summary and Wrapup
------------------
The meeting agreed to work toward LDAP interoperability.
Regarding a MIB: could be used to find the locations of the manageable
entities. The group should consider the possibilities.
A draft is out on expanding-ring search. Is there interest in adding this as
a possible SLP search mode? A comment here was that expanding-ring searches
don't always give you what you want (for example, pipe speed). The question
will go to the list.
Action: chair.
SVRLOC may not have to meet next time. In fact, it may be time to go dormant.
The template draft provides the process needed for IANA registration.