headers
Maureen.Stillman | 15 Mar 2004 20:59
Picon

Reliable Server Pooling Minutes from IETF #59

Please send any comments or questions to the list.  

-- maureen

Approximately 30 people attended the meeting at IETF #59.

Chairs:
Lyndon Ong; lyong <at> ciena.com
Maureen Stillman; maureen.stillman <at> nokia.com

We discussed the services document draft-ietf-rserpool-service-00.txt.  This document was recently
updated and posted to the list.  We request that people read the document and send comments to the list.   

Next we discussed the Rserpool architecture, draft-ietf-rserpool-arch-07.txt which is in IESG review. 
The IESG requested some changes to this document which raised some issues.  Specifically questions were
raised about whether the protocols should be split into more pieces to aid in its understanding and
possibly to aid in implementation.  This topic needs to be investigated further.

The comparison document draft-ietf-rserpool-comparison-07.txt was added to the agenda because the
issues raised by the reserpool architecture review also had impact on the comparison document.  Further
issues were raised by the AD review concerning evaluation of other IETF protocols such as Dynamic
Delegation Discovery System (DDDS) RFC 3401-6 and Extensible Provisioning Protocol (EPP)
draft-ietf-provreg-epp-09 in relation to Rserpool.  We need to evaluate these protocols and reach a
determination about their applicability to Rserpool.  Also the issue of using URN was raised.  Rserpool
uses pool handle names in ASCII format rather than URN.  This is due to issues such as hierarchy in the name
resolution process.  The Rserpool name space is not hierarchical.  The comment was that this seems to be an
architectural issue rather than a comparison document issue.

The Rserpool security threat document draft-ietf-rserpool-threats-02.txt is also in AD review. 
Comments were also received from the AD and have been added to -03.  This draft will be sent to be published
(Continue reading)

Permalink | Reply | 0 comments |
headers
Silverton Aron-C1710C | 17 Mar 2004 01:59

RE: Reliable Server Pooling Minutes from IETF #59

Maureen.Stillman <at> nokia.com <> wrote:
> Please send any comments or questions to the list.
> 
> snip   
> 
> Next we discussed the Rserpool architecture,
> draft-ietf-rserpool-arch-07.txt which is in IESG review.  The IESG
> requested some changes to this document which raised some issues. 
> Specifically questions were raised about whether the protocols should
> be split into more pieces to aid in its understanding and possibly to
> aid in implementation.  This topic needs to be investigated further. 
> 
> snip
> 
> -- maureen
> 

I'll weigh in here.  I agree that the current documents are at times difficult to understand and that there
are some nomenclature inconsistencies that should be rectified.  I've been party to several individuals
coming up to speed on RSERPOOL and always get the same comments about this stuff.  I'm not even sure myself,
based on title alone, what some of the drafts are all about.

For our internal efforts related to RSERPOOL, we have decided not to split the protocols and their
documentation up further, but instead to unify them in a single design document.  For a particular
RSERPOOL action, e.g., PE registration, we will describe both the ASAP and ENRP interactions between the
various system components.  I have also found that using the abstraction of a Service User (SU) to describe
both a PE and a PU in regards to the RSERPOOL Name Server (RNS) is often easier for those new to the protocol to
digest.  When the behavior of the PE and the PU differs, we then differentiate between the two entities.

While being somewhat aware of the historical reasons that things were partitioned and named as they are
(Continue reading)

Permalink | Reply | 0 comments |
headers
Maureen.Stillman | 17 Mar 2004 15:42
Picon

Security and Cookies -- IETF #59 issue

A question was raised at IETF #59 about the security of information in the cookies passed between the PE and
PU.  My response was that this is not mentioned in the threat document.  We are required to secure the
Rserpool infrastructure but not the application. In any case, I said I thought that this probably should
be brought up the threat document.

Cookies are passed via the Rserpool control channel.  In the case of TCP as the transport, the group reached
consensus that the data and control channel must always be multiplexed.  Therefore, the cases: 
a) control channel is secured; data channel is not
b) data channel is secured; control channel is not
are not allowed.  It is even hard to understand what this really means from a security point of view.

The agreement to require multiplexing results in the following cases:
1) the multiplexed control channel -data channel is secure OR
2) the multiplexed control channel - data channel is not secured
In my opinion, you get what you pay for and what makes sense.  If you are going to secure both the data and
control, then the cookies are secured.  If you are not going to secure the data and control; then the cookies
are not secured either.  Seems from this example that we made a good decision.

Any comments on this issue?  After we debate it I can add the consensus to the threat document if appropriate.

-- maureen
Permalink | Reply | 2 comments |
headers
Qiaobing Xie | 18 Mar 2004 01:59

Re: Security and Cookies -- IETF #59 issue

Maureen,

I am fully with you on this issue and agree with your assessment.

regards,
-Qiaobing

Maureen.Stillman <at> nokia.com wrote:

> A question was raised at IETF #59 about the security of information in the cookies passed between the PE and
PU.  My response was that this is not mentioned in the threat document.  We are required to secure the
Rserpool infrastructure but not the application. In any case, I said I thought that this probably should
be brought up the threat document.
> 
> Cookies are passed via the Rserpool control channel.  In the case of TCP as the transport, the group reached
consensus that the data and control channel must always be multiplexed.  Therefore, the cases: 
> a) control channel is secured; data channel is not
> b) data channel is secured; control channel is not
> are not allowed.  It is even hard to understand what this really means from a security point of view.
>   
> The agreement to require multiplexing results in the following cases:
> 1) the multiplexed control channel -data channel is secure OR
> 2) the multiplexed control channel - data channel is not secured
> In my opinion, you get what you pay for and what makes sense.  If you are going to secure both the data and
control, then the cookies are secured.  If you are not going to secure the data and control; then the cookies
are not secured either.  Seems from this example that we made a good decision.
> 
> Any comments on this issue?  After we debate it I can add the consensus to the threat document if appropriate.
> 
> -- maureen
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Tuexen | 18 Mar 2004 02:54
Picon

Re: Security and Cookies -- IETF #59 issue

Maureen,

one comment:
the cookie os reflected by the PU and provided by the PE to the APAP 
layer as a bytes
string. So it is up to the application to sign/encrypt the cookie in 
the case that
the PU<->PE communication is not secured. For the PU it does not 
matter. For the PE
the point is that the state required for signature verification and/or 
decryption
has to be shared between the PEs. But since all this is application 
level stuff this
should not be considered in RSerPool. The application level state 
sharing is out of
scope.

Best regards
Michael

On 18. Mar 2004, at 1:59 Uhr, Qiaobing Xie wrote:

> Maureen,
>
> I am fully with you on this issue and agree with your assessment.
>
> regards,
> -Qiaobing
>
> Maureen.Stillman <at> nokia.com wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Manuel Urueña | 25 Mar 2004 19:30
Picon

FYI: eXtensible Service Discovery Framework (XSDF)

Hi all,

As detailed in the rserpool-comparison draft, Rserpool architecture has
many similarities with the SLP one (DA<->ENRP Server, SA<->PE, UA<->PU),
although SLPv2 cannot be employed to fulfill all Rserpool requirements.

However, I've been studying this solution space, and I've designed an
evolution of SLPv2, called XSDF. Among other things, XSDF tries to be
compliant with the Rserpool requirements related to PE location and
selection. Therefore, XSDF tries to integrate service discovery and load
balancing in a single process.

XSDF is collection of 4 protocols designed to locate, register and keep
in sync Service information, including load balancing data. XSLP is
employed by UAs (PUs) to query DAs (ENRP Servers) for Service
information. SAs (PEs) employ XSRP to register its Service information
at DAs (then, ASAP = XSLP + XSRP + failover). XSSP and XSTP are employed
to keep DAs in sync (thus, ENRP = XSSP + XSTP).

XSDF provides several enhancements over SLP, as an extensible service
model, and remote service discovery capabilities. However, I think it
may also have some capabilities that could be useful for Rserpool:

- Service information may include some attributes to allow PUs to select
the better PE from the Pool, as in current Rserpool specifications.
However, in XSDF, PEs may also specify load balancing parameters when
registering a Service at an ENRP server. In that case, the ENRP server
performs a selection process when queried by a PU, and returns the list
of available PEs to the PU, sorted by preference. Also, both selection
processes may be combined, for example the ENRP servers may apply a
(Continue reading)

Permalink | Reply | 0 comments |

Gmane