Rserpool: Reliable Server Pooling
Co-chairs: Lyndon Ong, lyong@ciena.com
Maureen Stillman, maureen.stillman@nokia.com
IETF 53 Monday March 18, 2002
13:00 - 15:00

Approximately 60 people attended this meeting.

Agenda:

1)  Rserpool Architecture document
 draft-ietf-rserpool-arch-01.txt
 Michael Tuexen

2)  Rserpool Comparison document
 draft-ietf-comp-03.txt
 John Loughney

3) Rserpool MIB document
draft-mulik-rserpool-mib-00.txt
Phillip Conrad

4) Threat document  and Rserpool security
 draft-stillman-rserpool-threats-02.txt
 Maureen Stillman

5)  Rserpool ASAP document
 draft-ietf-rserpool-asap-02.txt
 Randy Stewart

6)  Rserpool ENRP document
 draft-ietf-rserpool-enrp-02.txt
 Qiaobing Xie

1)  Rserpool Architecture document
The Rserpool architecture document was discussed.  Several issues were raised: The use of multicast needs to be clarified.  Where should we put the security work?  In this document or some other document?  Should we define APIs or psuedocode?  A comment was made that the services offered by Rserpool are not defined.  What do the Rserpool protocols offer to the application?  A service model is necessary.  It is not clear from the document if Rserpool is transparent to the application or not, for example.

It was determined that APIs or psuedocode are not appropriate for an architecture document.  It was agreed by the group that more explanation of the services that Rserpool would offer to applications needs to be documented, and Loede Coene volunteered to draft an applicability statement that would provide such material.  Further comments on the architecture document are welcome.

2)  Rserpool Comparison document
The comparison document was discussed.  Updated text on CORBA and SLP has been added.  One attendee brought up possible relevance of the Sever Cache Synchronization Protocol (SCSP) RFC 2334 to Rserpool.  It was requested that further information about SCSP and potential relationship to Rserpool be posted to the list.  It may offer a complementary set of functions.  It could potentially solve problems like state sharing.  Further review of the comparison document was felt to be required before progressing it further.

3) Rserpool MIB document
A draft MIB has been completed for Rserpool by Phil Conrad and students and was submitted as an I-D.  There may be an open source implementation available in September.  SCTP bakeoffs might be a good venue.  The AD asked that the MIB group work with experienced MIB writers for feedback and guidance.  The MIB document was progressed to a Rserpool WG document by group consensus.

4) Threat document  and Rserpool security
The security design team discussed Rserpool security for several months and reached a consensus.  This consensus was discussed and problems with the end user security in exchanges with the ENRP server for name resolution were surfaced.   It is possible for a malicious ENRP server to masquerade as a legitimate ENRP server.  The user must be protected from this threat. Therefore, a security mechanism to authenticate the ENRP server  to the end user will be added.  The MIDCOM WG is dealing with similar security issues.  We must think about where the credentials come from.  Someone recommended that we look at Kerberos.   We need to keep a watch on the IPSec WG for its revisions of the IKE protocol known as "son of IKE".  It was recommended that we look at Eric Rescorla's document on how to write a security considerations section.  The end user - ENRP server authentication problem is the next task that the security design team will tackle.

5,6)  Rserpool ASAP and ENRP documents

ASAP was not revised much from previous IETF meeting.  There are a number of open issues.  One major issue is that Rserpool currently only supports SCTP as its transport for end user applications.  This needs to be modified to include other transport protocols such as TCP and UDP.   We cannot expect all applications to change their transport protocols.   We need to clarify the use of multicast.  Name space auditing and synchronization need to be addressed.  Pluggable server selection policies were discussed in the past but not defined in detail.  We need to determine the impact of NATs and address scoping of IP addresses in IPv6.

Closing Remarks:

There was consensus that the WG needs a working meeting on the ASAP, ENRP protocols and the architecture document.  An interim meeting will be announced on the mailing list in accordance with IETF guidelines.  Cisco offered to host the meeting.