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

[Lou Berger <[e-mail]>]

I agree, a fine start.  There's room to add/relocate in the future.

Thanks!

Lou

On 08/14/2013 01:49 PM, Joe Marcus Clarke wrote:
> 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
>>
> 
>