Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01

I am going to publish an updated version of draft-atlas-i2rs-architecture
without fully addressing this point.

I did add in a new subsection (6.4.1 Client Redundancy) under 6.4 Identity
and Security Role that says:

"I2RS must support client redundancy.  At the simplest, this can be
handled by having a primary and a backup network application that both
use the same client identity and can successfully authenticate as
such.  Since I2RS does not require a continuous transport connection
and supports multiple transport sessions, this can provide some basic
redundancy.  However, it does not address concerns for troubleshooting
and accountability about knowing which network application is actually
active.  At a minimum, basic transport information about each
connection and time can be logged with the identity.  Further
discussion is necessary to determine whether additional client
identification information is necessary.[[Editor's
note: This requires more discussion in the working group.]]"

Alia

On Thu, Aug 1, 2013 at 7:28 PM, Joe Marcus Clarke <jclarke@cisco.com> wrote:

> On 8/1/13 11:19 AM, Alia Atlas wrote:
> > Joe,
> >
> > Ok - so what I hear from you is needed is the
> >    client role
> >    client identity
> >    sub-client identity?
> >
> > Where the permissions and ownership of state is tied to the client role?
> >  Does that match to what you are saying?  I believe we're assuming that
> > the ownership of state is tied to the client identity - and you are
> > suggesting that if so, we need a client sub-identity or such?
>
> Yes, I think that is in line with what I'm suggesting.  If we can allow
> Client A to assume the identity of Client B using the same credentials,
> I would want some way to know that this is indeed Client B now acting on
> behalf of either itself or some northbound controller.
>
> Joe
>
> >
> > Alia
> >
> >
> > On Thu, Aug 1, 2013 at 11:15 AM, Joe Marcus Clarke <jclarke@cisco.com
> > <mailto:jclarke@cisco.com>> wrote:
> >
> >     On 8/1/13 11:11 AM, Joel Halpern wrote:
> >     > The client is the entity that is authenticated and authorized. If
> the
> >     > client is acting on behalf of someone else, we assume that the
> >     > authentication and authorization of that party is the task of the
> >     client
> >     > and outside our scope. However we include that identity so that
> >     actions
> >     > can be easily correlated with originators.
> >
> >     Right.  I get that.  I had thought we were talking about two clients
> >     that might be redundant to each other where Client 1 dies and Client
> 2
> >     assumes its identity to make changes possibly driven by northbound
> >     actors.  Even in this case, I feel Client 2 still needs to maintain a
> >     unique identification to the I2RS agent so that one can trace the
> >     operation back to the specific I2RS client (in addition to the
> >     northbound actor).
> >
> >     Joe
> >
> >     >
> >     > Yours,
> >     > Joel
> >     >
> >     > Sent from my Android phone using TouchDown (www.nitrodesk.com
> >     <http://www.nitrodesk.com>)
> >     >
> >     > -----Original Message-----
> >     > *From:* Joe Marcus Clarke [jclarke@cisco.com
> >     <mailto:jclarke@cisco.com>]
> >     > *Received:* Thursday, 01 Aug 2013, 17:07
> >     > *To:* Alia Atlas [akatlas@gmail.com <mailto:akatlas@gmail.com>]
> >     > *CC:* Lou Berger [lberger@labn.net <mailto:lberger@labn.net>];
> >     i2rs@ietf.org <mailto:i2rs@ietf.org> [i2rs@ietf.org
> >     <mailto:i2rs@ietf.org>]; Joel
> >     > Halpern [joel.halpern@ericsson.com <mailto:
> joel.halpern@ericsson.com>]
> >     > *Subject:* Re: [i2rs] Provisions for Client Redundancy/Fault
> Tolerance
> >     > in draft-atlas-i2rs-architecture-01
> >     >
> >     > On 8/1/13 7:51 AM, Alia Atlas wrote:
> >     >> Not to answer for Joel, but my view is that a client is
> identified by
> >     >> its identity.  A different application can take over from the
> >     first by
> >     >> using the same identity.  Loss of a transport session does not
> cause
> >     >> existing client state to be removed (in the architecture) - so
> >     there is
> >     >> the ability for a new application to take over.
> >     >>
> >     >> Does that help?
> >     >
> >     > That worries me without more discussion about authentication.
> >     > Additionally, from a troubleshooting standpoint, if I can assume
> the
> >     > same identity as another client, how can I be absolutely sure which
> >     > client does what to the agent?  I feel there needs to be more to
> >     ensure
> >     > accountability of what client does what, certainly from a security
> >     > perspective, but also from a troubleshooting perspective.
> >     >
> >     > Joe
> >     >
> >     >>
> >     >> Alia
> >     >>
> >     >>
> >     >> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger <lberger@labn.net
> >     <mailto:lberger@labn.net>
> >     >> <mailto:lberger@labn.net <mailto:lberger@labn.net>>> wrote:
> >     >>
> >     >>     Hi Joel,
> >     >>             In today's session, I asked about provisions in the
> >     architecture
> >     >>     (document) for Client Redundancy/Fault Tolerance. I believe
> >     you stated
> >     >>     that "it's not needed" and that you'd elaborate on the list.
> >     >>
> >     >>     I believe you also answered a latter question by stating that
> >     clients
> >     >>     are free to coordinate between themselves to provide
> >     redundancy. Is this
> >     >>     the simple answer?  If not, can you elaborate?
> >     >>
> >     >>     Thanks,
> >     >>     Lou
> >     >>     _______________________________________________
> >     >>     i2rs mailing list
> >     >>     i2rs@ietf.org <mailto:i2rs@ietf.org> <mailto:i2rs@ietf.org
> >     <mailto:i2rs@ietf.org>>
> >     >>     https://www.ietf.org/mailman/listinfo/i2rs
> >     >>
> >     >>
> >     >>
> >     >>
> >     >> _______________________________________________
> >     >> i2rs mailing list
> >     >> i2rs@ietf.org <mailto:i2rs@ietf.org>
> >     >> https://www.ietf.org/mailman/listinfo/i2rs
> >     >>
> >     >
> >     >
> >     > --
> >     > Joe Marcus Clarke, CCIE #5384,         |          |
> >     > SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
> >     > Distinguished Services Engineer ..:|||||||||::|||||||||:..
> >     > Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%29%20392-2867>
> >     c i s c o  S y s t e m s
> >     > Email: jclarke@cisco.com <mailto:jclarke@cisco.com>
> >     >
> >     >
> >
> ----------------------------------------------------------------------------
> >
> >
> >     --
> >     Joe Marcus Clarke, CCIE #5384,         |          |
> >     SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
> >     Distinguished Services Engineer ..:|||||||||::|||||||||:..
> >     Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%29%20392-2867>         c
> >     i s c o  S y s t e m s
> >     Email: jclarke@cisco.com <mailto:jclarke@cisco.com>
> >
> >
> ----------------------------------------------------------------------------
> >
> >
>
>
> --
> Joe Marcus Clarke, CCIE #5384,         |          |
> SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
> Distinguished Services Engineer ..:|||||||||::|||||||||:..
> Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
> Email: jclarke@cisco.com
>
>
> ----------------------------------------------------------------------------
>