Subject: RE: [Rserpool] RE: Erik Guttman's comments on Rserpool threats for review and comment

From: "Sengodan Senthil (NRC/Boston)" <[email-masked]>
Date: Tue, 4 Sep 2001 20:06:44 -0500

Erik Guttman wrote:

> 
> If an application relies on IPSec for security, RSERPOOL will 
> break this.  

It seems that the general way to handle this could be one of two ways:

(1) To pre-establish one/more alternative IPSec security associations
(SA) that can be used should the primary SA become unusable (due to
server failure). No context sharing is done between SAs that are
terminated at the different servers.
(2) To enable the same SA across multiple servers, and share the
security context across them. In this case, if the primary SA fails,
then a seamless transfer to the other servers is possible since the
security context is synchronized.

I think that we will have to leverage off efforts within seamoby for
this, and adapt it to rserpool's needs.

- Senthil

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

---

From: Erik Guttman <[email-masked]>
Date: Wed, 5 Sep 2001 10:56:28 +0200 (MET DST)

> > If an application relies on IPSec for security, RSERPOOL will 

Allow me to clarify.  If you use IPsec naively - associating app
security on a fixed security association between two endpoints,
(like with static prekeying) RSERPOOL will break this.

I did not mean to imply that IPSec and RSERPOOL can't be made
compatible.

> terminated at the different servers.

I think I agree with you, if I what you are saying is:

    PU                           PE1        PE2
   ====                         ====       ====
    IP  SA1 -----------------SAa IP    /SA* IP
        SA2 --------------------------+

In this case PU has a separate SA with PE1 and PE2, call them SA1 and
SA2.  In this case, the transport and RSERPOOL interactions, as well
as the application data is (a) protected (b) authenticated by IPsec.
I call the SAs by different names on the PE sides since its important
to note the problem is symmetric - you need association to be built
from each pool member back to each pool user.

The issue I see with this approach is the coordination between the
rserpool layer and the IPsec layer.  In particular, you need to 
establish n SAs for each PU, where n is the number of PEs.  This
need not be done immediately:  There's the usual trade off of
eager/lazy processing.

> security context is synchronized.

Actually its easier than you think.  Since this is network layer
security, a break in the flow of communication can be handled by
the transport layer.  The security state associated with the IPsec
communication flow can be initialized & established with a different
flow - to a different agent, in the case where RSERPOOL decides to
redirect traffic.  The challenge is still at the higher layers -
doing application state context transfer.

Time
  |   PU             PE1           PE2
  v  ====           =====         =====
       A!
       o-----
              \
               ----->
            B  -----o SA(x)
             /
   SA(x)<----   C
            <======>
   
       D!        
       o------------------
                          \
                           ----->
                        E  -----o SA(y)
                          /
   SA(y)<-----------------   F
        <=======================>

A!  RSERPOOL decides to direct PU traffic to PE1
B   Establish SA and associated state between PU and PE1
    (like cypher block vectors)
C   Communicate between PU and PE1.  Stateful changes to SA(x) state
    continue to occur on both sides of the communication.
D!  RSERPOOL decides to redirect PU traffic to PE2
    Note that a distinct SA must be established between PU and PE2.
    The entire state between PU and PE1 can be tossed, or saved for
    future communication between PU and PE1.
E   Establish SA and associated state between PU and PE2
F   Communicate between PU and PE1.  Stateful changes to SA(y) state
    continue to occur on both sides of the association.

> this, and adapt it to rserpool's needs.

I am not sure this is necessary.  We are not trying to make PE1 and
PE2 seem equivalent or fix changes due to communication context.
The seamoby problem is to maintain communication between the same
endpoints when a mobile host's communication context changes (ie.
their care of address, the forwarding path, etc.)  The RSERPOOL 
problem is to allow upper layer flexibility via different transport
paths.  The network layer is largely isolated from this.  Indeed,
a transport like SCTP will allow transparent recovery across 
different L3 endpoints (with distinct security associations) as a
service to higher layers.

Erik