RE: Where do we go from here?

["Ken Crozier" <kcrozier@cisco.com>]

Randy,

The model i see going forward is that there are: Applications, boxes and
humans. Boxes will receive data from Applications and humans. When Humans
connect to the boxes they are most likely going to type in CLI. The
connection between the applications and the Boxes is what i was referring
to. So between an Application and a box should there be a command channel
and a data channel. The commands sent down through the command channel would
be something like 'download/receive a software image'. The box would then
download/receive the file through the data channel. This still leaves a
method for the application to get to the box whilst the image is being
downloaded. Having run an Enterprise network some years ago, we struggled
with this problem and ended up doing it the hard way by sending people. It
would have been much easier to have a method of terminating the download
without having to have somebody on site to kick the box...

As to the transport i totally agree that there are plenty of transports out
there and all that should have to be done is pick one of a bunch from SSH,
BEEP, SCTP etc. But how do we do that without asking a lot of questions of
what the transport should be ?

As to security, you are quite correct that the model has to be defined. But
is it any different from apps talking to boxes, and humans talking to boxes.
There are two methods to ensure that the commands and data the box just
received came from a trusted friend, one is to establish trusted domains,
the second is to trust no-one and therefore the box has to authorize each
and every command it gets. As to the transport being protected we have to
define what level is adequate as some countries frown upon encryption, and
whether or not an Authenticated header is needed.

I too, care that it is done well. Not trying to threaten anyone, just asking
questions !!

Ken

-----Original Message-----
From: owner-xmlconf@ops.ietf.org [mailto:owner-xmlconf@ops.ietf.org]On
Behalf Of Randy Bush
Sent: Friday, August 09, 2002 3:32 PM
To: Ken Crozier
Cc: xml list
Subject: RE: Where do we go from here?


as no one else seems interested enough to play, i'll hit the ball

> Do we need multiple channels to each device ? Say a data channel and a
> command channel

please explain the difference between data and commands, maybe by
example.  i.e. i suspect some folk think the entire model will be
encoded in a single stream/file/whateveryoucallit.  and i fear that
much confusion is thereby caused.  so it would be good to further
expose this part of the discussion.

> Do we need sequence numbers ?

sequences of what?  i.e. numbers to uniquify what?

> Do we need retires ?

do you mean does the transport have to be reliable?  if it does, we
have pretty standard ways of doing reliable transports.  and i
think they use retries among 42 other transport trix.  i hope we
don't have to reinvent this.

> Security
> All this needs to be done securely

whatever that means.  that's kinda like "it has to be done well"

> Is it good enough to have trusted domains between the server &
> the client, or must each and every command be authorized by the
> end user.

i don't think we have yet clearly defined the identities in the
authorization model.

> Do we need to authenticate each and every packet
> How do we authenticate the server and client

> Do we care about certificates

certificates are merely a tool to accomplish some goals which have
not yet been clearly specified or agreed.  so this question is not
answerable.

and what are the privacy requirements?  i.e. must data be protected
in transport?

> There is work that needs to do be done in this area. Either the
> IETF does it or other groups will.

i hope i am not supposed to feel threatened by such statements.  i
care that it is done well.

randy


--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>


--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>