headers
Maureen.Stillman | 6 Oct 2003 21:48
Picon

RE: 58th IETF meeting

We have a slot on the draft agenda on Monday afternoon, November 10 for 2 hours 15:30 to 17:30.  Subject to
change, of course, until the agenda is finalized.

-- maureen

-----Original Message-----
From: ext Silverton Aron-C1710C [mailto:Aron.J.Silverton <at> motorola.com]
Sent: Tuesday, September 30, 2003 11:00 AM
To: 'rserpool <at> ietf.org'
Subject: [Rserpool] 58th IETF meeting

Maureen and Lyndon,

Any idea when we will meet in Minneapolis?  The earlier in the week would be best for me personally.

Regards,

Aron

Aron J. Silverton
Senior Staff Research Engineer
Motorola Labs, Networks and Infrastructure Research
Motorola, Inc.

Telephone: 847-576-8747    
Fax: 847-576-3240
mailto:Aron.J.Silverton <at> motorola.com

_______________________________________________
rserpool mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Dreibholz | 7 Oct 2003 11:56
Picon

Download ENRP Namespace Data from Mentor Peer


Hi all,

when an ENRP server requests a namespace copy from a mentor peer by multiple 
PEER_NAME_TABLE_REQUEST / PEER_NAME_TABLE_RESPONSE cycles during startup, the 
mentor peer must also transmit PEER_NAME_UPDATES to the requesting name 
server. Otherwise, namespace inconsistency can be caused.

Example without PEER_NAME_UPDATE:
1. PEER_NAME_TABLE_RESPONSE with information about PE1.
2. PE1 updates its policy parameters or deregisters.
3. PEER_NAME_TABLE_REQUEST -> PEER_NAME_TABLE_RESPONSE with remaining parts of 
the namespace.
=> The requesting nameserver still has PE1's old data.

Example with PEER_NAME_UPDATE:
1. PEER_NAME_TABLE_RESPONSE with information about PE1.
2a. PE1 updates its policy parameters or deregisters.
2b. PEER_NAME_UPDATE for PE1.
The new name server can update the PE1 entry or remove it.
3. PEER_NAME_TABLE_REQUEST -> PEER_NAME_TABLE_RESPONSE with remaining parts of 
the namespace.

Therefore, section 4.2.3 of the ENRP draft should be extended by requiring the 
mentor peer to send PEER_NAME_UPDATEs and the new nameserver to handle these 
messages.

Best regards
--

-- 
=======================================================================
(Continue reading)

Permalink | Reply | 1 comment |
headers
Maureen.Stillman | 7 Oct 2003 23:22
Picon

Rserpool Agena for IETF #58

Rserpool Agena for IETF #58; Monday November 10, 2003

We need to work on the draft agenda for our 2 hour slot.  Please send any topics to me and I'll work up a draft
agenda for the mailing list.

Thanks.

-- maureen
Permalink | Reply | 0 comments |
headers
Qiaobing Xie | 8 Oct 2003 00:45

Re: Download ENRP Namespace Data from Mentor Peer

Hi, Thomas,

The issue you discuss here is simply a race condition between ASAP and
ENRP. Since ASAP and ENRP are two separately protocols, there will be a
lot of race conditions that could occur in operation. And we realize
this situation from very beginning. Our strategy has been to allow the
discrepancies to occur and to rely on the auditing and re-sync
procedures to bring the name servers back to consistency. The reasoning
is simply - it would be too expensive to address the race conditions one
by one and it wouldn't make much sense either if we only address one
race condition without fixing the others... So my view is to stay with
the overall design strategy and let the auditing and re-sync procedures
to take care of the inconsistency.

regards,
-Qiaobing

Thomas Dreibholz wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all,
> 
> when an ENRP server requests a namespace copy from a mentor peer by multiple
> PEER_NAME_TABLE_REQUEST / PEER_NAME_TABLE_RESPONSE cycles during startup, the
> mentor peer must also transmit PEER_NAME_UPDATES to the requesting name
> server. Otherwise, namespace inconsistency can be caused.
> 
> Example without PEER_NAME_UPDATE:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Silverton Aron-C1710C | 8 Oct 2003 01:40

RE: Download ENRP Namespace Data from Mentor Peer

Hi Thomas and Qiaobing,

As Qiaobing pointed out there are many possible race conditions that can
occur depending on who the home ENRP server for the PE is and who the mentor
peer server for the new ENRP server is.  That being the case, the
PEER_NAME_UPDATE would seem to make more sense if the PE that changes its
information or deregisters is homed to the ENRP server acting as the mentor.
In any event, everything will get straightened out eventually, but I could
go so far as suggesting that:

Upon receiving the final PEER_NAME_TABLE_RESPONSE from the mentor peer, the
new ENRP server SHOULD initiate the audit and synchronization procedures to
account for any race conditions that may be existed during the initial name
space transfer.

This is probably more along the lines of a best practice or an
implementation note, and perhaps it doesn't belong in the protocol draft.

Aron

Xie Qiaobing-QXIE1 wrote:
> Hi, Thomas,
> 
> The issue you discuss here is simply a race condition between
> ASAP and ENRP. Since ASAP and ENRP are two separately protocols,
> there will be a lot of race conditions that could occur in
> operation. And we realize this situation from very beginning. Our
> strategy has been to allow the discrepancies to occur and to rely
> on the auditing and re-sync procedures to bring the name servers
> back to consistency. The reasoning is simply - it would be too
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 7 Oct 2003 17:07
Picon
Favicon

I-D ACTION:draft-ietf-rserpool-threats-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Server Pooling Working Group of the IETF.

	Title		: Threats Introduced by Rserpool and Requirements 
			  for Security in response to Threats
	Author(s)	: M. Stillman, et. al.
	Filename	: draft-ietf-rserpool-threats-02.txt
	Pages		: 10
	Date		: 2003-10-7
	
Rserpool is an architecture and protocols for the management and
access to server pools supporting highly reliable applications
and for client access mechanisms to a server pool. This Internet
draft describes security threats to the Rserpool architecture and
presents requirements for security to thwart these threats.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rserpool-threats-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rserpool-threats-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Tuexen | 12 Oct 2003 21:27
Picon

Re: Comments on architecture document -- last call

Hi Maureen,

see my comments below.

Best regards
Michael

On Aug 19, 2003, at 22:38, Maureen.Stillman <at> nokia.com wrote:

> I read this carefully.  Here are my comments.
>
Thank you very much.
> Non-nits:
>
> 2.2.1 Endpoint Name Resolution Protocol
>
>    The name servers use a protocol called Endpoint Name Resolution
>    Protocol (ENRP) for communication with each other to make sure that
>    all have the same information about the server pools.
>
> I'm concerned that this will spark a lengthy debate about 
> synchronization of ENRP databases.  We can't guarantee instantaneous 
> updates of the database and a perfectly synchronized name space.  How 
> about something like:
>
>    The name servers use a protocol called Endpoint Name Resolution
>    Protocol (ENRP) for communication with each other to exchange 
> information and updates
>    about the server pools.
Accepted.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Tuexen | 12 Oct 2003 22:14
Picon

Re: Comments on the Rserpool architecture internet draft -- last call

Maureen,

I've included the section in the document as requested.

Best regards
Michael

On Aug 18, 2003, at 22:49, Maureen.Stillman <at> nokia.com wrote:

> There is no security considerations section in the architecture draft.  
>  I should have caught this earlier -- my bad!
>
> Here is a suggestion:
>
> The Rserpool protocol must allow us to secure the Rserpool  
> infrastructure.  There are security and privacy issues that relate to  
> the namespace, pool element registration and user queries of the  
> namespace.  In [1] a complete threat analysis of Rserpool components  
> is presented.
>
> [1] Threats Introduced by Rserpool and Requirements for Security in  
> response to Threats, draft-ietf-rserpool-threats-00.txt, work in  
> progress.
>
> This is how it is handled in the OPES architecture document  
> http://www.ietf.org/internet-drafts/draft-ietf-opes-architecture 
> -04.txt.
>
> I have some nits, but I'll send them tomorrow.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Tuexen | 12 Oct 2003 23:02
Picon

New version of draft-ietf-rserpool-arch-07.txt

Dear all,

I have just submitted a new version of the architecture document.
It is also available at
http://www.sctp.de/internet-drafts.html

The changes include
- removal of Maureen and Lyndon from the list of authors to reduce
   the number of authors.
- inclusion of the comments during the WG last call (mainly from 
Maureen).
- floating around some figures to no have them split on two pages.
- inclusion of the security considerations referring to the threats ID.

What I missed: include Maureen and Lyndon in the Acknowledgment section.
I will add this for the next version. I'm sorry for this.

Best regards
Michael
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 13 Oct 2003 21:57
Picon
Favicon

I-D ACTION:draft-ietf-rserpool-arch-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Server Pooling Working Group of the IETF.

	Title		: Architecture for Reliable Server Pooling
	Author(s)	: M. Tuexen, Q. Xie, et. al.
	Filename	: draft-ietf-rserpool-arch-07.txt
	Pages		: 22
	Date		: 2003-10-13
	
This document describes an architecture and protocols for the
management and operation of server pools supporting highly reliable
applications, and for client access mechanisms to a server pool.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rserpool-arch-07.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rserpool-arch-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane