Subject: [Rserpool] Rserpool IETF #67 minutes

From: <[email-masked]>
Date: Mon, 20 Nov 2006 13:00:28 -0600

Any comments on the minutes?  I'll be posting them to the proceedings
soon.  The deadline is Dec. 8, but I want to get this in early.

Rserpool Overview - Lyndon Ong 
draft-ietf-rserpool-overview-00.txt 

We have decided to replace the architecture document with an overview of
Reliable Server Pooling.  Lyndon asked for comments on the document to
be sent to the list.  

Rserpool threats - Maureen Stillman 
draft-ietf-rserpool-threats-05.txt 

We reviewed the trust argument for rserpool.  The presentation consisted
of a discussion of each threat against each architectural component of
Rserpool and included the threats posed by interactions between
components.  In each case, a mitigation was proposed for the threat.  A
high level summary of the mitigations required are: confidentiality,
authentication, integrity, protection from replay attacks and protection
from man in the middle attacks.  TLS was selected as the security
mechanism which meets these requirements.  We discussed the issue of
ENRP databases with mixed entries; some from secure PE and some from
unsecured PE.  It was decided that mixed entries are insecure and we
agreed to send a security error message from a secure ENRP server to a
unsecured PE indicating that it is trying to register with a secure ENRP
server.  Alternatively, the ENRP server could listen only on 443 and any
message not using TLS will be rejected.  We will modify the protocol
documents to add this error message.

ENRP Implementation Status - Michael Tuexen 

Michael presented an ENRP implementation that was coded just from
reading the ENRP protocol specification.  A number of specification
issues were identified, such as what messages can use the multicast
channel, handling of takeover requests with a non-responding server and
topological connection of servers.  It was commented that an implicit
handling of the takeover case that was used in the original
implementation was to take any non-responding servers off the list of
active servers.  Michael agreed that this is reasonable but needs to be
documented in the ENRP protocol.  We will modify the ENRP document to
add this explanation.

Address scoping - Michael Tuexen 
Michael presented an issue with the addresses returned by the ENRP
server. Part of the issue concerns SCTP address scoping drafts that are
expired and need to be resubmitted, part has to do with defining
Rserpool-specific aspects. The AD asked if documenting the SCTP issues,
independent of Rserpool, was important. The general view was that this
was important and that the desired action would be to resubmit the SCTP
drafts as well as documenting Rserpool specific aspects.  However, as a
fallback, in case the SCTP drafts do not progress well we could document
all aspects of address scoping in a Rserpool document.  The next step
will be to resubmit the expired SCTP documents.

ASAP - Randy Stewart 
draft-ietf-rserpool-asap-14.txt 
Randy noted that he had done a major update on the ASAP specification
and has addressed all of the major issues, except for a security update
based on the recent threats work described above.  The draft
specification for this update was included in the latest ASAP draft.

Rserpool Interop - Randy Stewart 

Randy reported on the results of an Rserpool Interop held in Vancouver
in July.  At the Interop there were  two ASAP implementations, one from
Cisco and one from University of Essen, and one ENRP implementation.
These were tested in an ad hoc manner but were found to work together
successfully.  200 ENRP server processes were run simultaneously to test
the ENRP implementation.

Next steps: 

The WG reached consensus on submitting the documents as experimental.
The following documents will comprise the Rserpool package that will be
submitted to the IESG:

Overview 
ASAP 
ENRP 
Common parameters 
Threat document 
Policy 

We will update these documents based on the comments from the WG meeting
and submit the package to an external reviewer.

-- Maureen 
Maureen Stillman 
Nokia Enterprise Solutions 

_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool