[i2rs] info-model for traceability and accountability??

[Alia Atlas <[e-mail]>]

I am pulling this into a separate thread because I think that it merits
some discussion.
There seems to be a strong desire for easy
traceability/accountability/troubleshooting that is better than just syslog
or screen-scraping - something that is vendor-agnostic.

The idea of having the I2RS Agent store all the operations and attribution
done is not appealing.  Clearly, the most recent writer of data will need
to be stored.

Perhaps an info-model would be useful - and then an I2RS agent could write
the data to a file in a structured format?  Perhaps there needs to be some
specific interactions with the files - ability to fetch, rotate, clear?
 I'm not sure what's needed.

Should this be the same info-model that describes the connections to the
I2RS agent and relevant information and counters?

Do we have anyone motivated and interested in this particular area enough
to write up a short/quick draft and drive discussion?

Thanks,
Alia

On Wed, Aug 14, 2013 at 1:49 PM, Joe Marcus Clarke <[e-mail]>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
> >
>
>
> --
> 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]
>
>
> ----------------------------------------------------------------------------
>