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

[Joe Marcus Clarke <[e-mail]>]

On 8/13/13 4:58 PM, Alia Atlas wrote:
> 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.]]"

This is fine as a start.  I would want to strengthen the language to
ensure that an I2RS Agent always stores Client connection information
with a timestamp.  This information should be queriable via I2RS (with
appropriate read scope).

Joe

> 
> Alia
> 
> 
> On Thu, Aug 1, 2013 at 7:28 PM, Joe Marcus Clarke <[e-mail]
> <mailto:[e-mail]>> 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
>     <[e-mail] <mailto:[e-mail]>
>     > <mailto:[e-mail] <mailto:[e-mail]>>> 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>
>     >     <http://www.nitrodesk.com>)
>     >     >
>     >     > -----Original Message-----
>     >     > *From:* Joe Marcus Clarke [[e-mail]
>     <mailto:[e-mail]>
>     >     <mailto:[e-mail] <mailto:[e-mail]>>]
>     >     > *Received:* Thursday, 01 Aug 2013, 17:07
>     >     > *To:* Alia Atlas [[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>]
>     >     > *CC:* Lou Berger [[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>];
>     >     [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>> [[e-mail] <mailto:[e-mail]>
>     >     <mailto:[e-mail] <mailto:[e-mail]>>]; Joel
>     >     > Halpern [[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>]
>     >     > *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
>     <[e-mail] <mailto:[e-mail]>
>     >     <mailto:[e-mail] <mailto:[e-mail]>>
>     >     >> <mailto:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>> 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
>     >     >>     [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>> <mailto:[e-mail]
>     <mailto:[e-mail]>
>     >     <mailto:[e-mail] <mailto:[e-mail]>>>
>     >     >>     https://www.ietf.org/mailman/listinfo/i2rs
>     >     >>
>     >     >>
>     >     >>
>     >     >>
>     >     >> _______________________________________________
>     >     >> i2rs mailing list
>     >     >> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>     >     >> https://www.ietf.org/mailman/listinfo/i2rs
>     >     >>
>     >     >
>     >     >
>     >     > --
>     >     > Joe Marcus Clarke, CCIE #5384,         |          |
>     >     > SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
>     >     > Distinguished Services Engineer ..:|||||||||::|||||||||:..
>     >     > Phone: [phone] <tel:%2B1%20%28919%29%20392-2867>
>     <tel:%2B1%20%28919%29%20392-2867>
>     >     c i s c o  S y s t e m s
>     >     > Email: [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >     >
>     >     >
>     >    
>     ----------------------------------------------------------------------------
>     >
>     >
>     >     --
>     >     Joe Marcus Clarke, CCIE #5384,         |          |
>     >     SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
>     >     Distinguished Services Engineer ..:|||||||||::|||||||||:..
>     >     Phone: [phone] <tel:%2B1%20%28919%29%20392-2867>
>     <tel:%2B1%20%28919%29%20392-2867>         c
>     >     i s c o  S y s t e m s
>     >     Email: [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >
>     >    
>     ----------------------------------------------------------------------------
>     >
>     >
> 
> 
>     --
>     Joe Marcus Clarke, CCIE #5384,         |          |
>     SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
>     Distinguished Services Engineer ..:|||||||||::|||||||||:..
>     Phone: [phone] <tel:%2B1%20%28919%29%20392-2867>         c
>     i s c o  S y s t e m s
>     Email: [e-mail] <mailto:[e-mail]>
> 
>     ----------------------------------------------------------------------------
> 
> 
> 
> 
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
> 


-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: [phone]         c i s c o  S y s t e m s
Email: [e-mail]

----------------------------------------------------------------------------