RE: SACRED Protocol (long!)

I'd like to observe a point that hasn't been too visible in this discussion,
but which seems significant. Relative to most applications, SACRED is quite
a special case. As far as security (its reason for existence) is concerned,
SACRED is a bootstrap protocol; by necessity, many of the prerequisites that
many underlying security mechanism candidates need in order to provide
protection won't be in place until after the SACRED exchange is completed.
To protect the SACRED exchange itself, only a restricted set of mechanisms
can be applicable; SACRED's requirements are sufficiently special that the
mechanisms it needs and uses may not be used for any other purposes.  As
such, there'll be limited independence in practice between the SACRED
application and its underlying mechanism.  

As far as transport integration is concerned, is there any existing practice
in evaluating how effectively and comprehensively non-BEEP transports can be
applied to implement the BEEP interface?  As applications go, I think
SACRED's transport requirements will be fairly simple (e.g., purely
synchronous exchanges), but other applications where SACRED might be
incorporated as an element will probably establish their transport choices
against their own priorities and constraints.

--jl

> -----Original Message-----
> From: Dave Crocker [mailto:[email protected]]
> Sent: Sunday, December 09, 2001 12:24 PM
> To: Nystrom, Magnus
> Cc: Marshall T. Rose; [email protected]; Marshall Rose
> Subject: Re: SACRED Protocol (long!)
> 
> 
> 
> At 11:50 AM 12/7/2001 -0500, Magnus Nystrom wrote:
> >SACRED in the form proposed this week by me is quite self-sufficient
> >and puts very few requirements on the protocol it runs on top of.
> 
> Magnus,
> 
> This is the core of your error.  You want Sacred to do too much work.
> 
> An essential part of making a successful protocol standard is 
> to have it do 
> no more than is essential.  That is the entire reason for layering.
> 
> Hence, define a protocol that does only the new part that you need 
> done.  Then define a functional interface below that 
> protocol, thereby 
> specifying all the "infrastructure" services you need from 
> the layer(s) 
> below.  The new protocol is the client of that interface.
> 
> Then map one or more lower layers -- as providers -- to 
> supply the required 
> services.
> 
> As a matter of well-engineered convenience, BEEP supplies a 
> very useful 
> functional interface to client applications.
> 
> So the way to do what YOU want is not to have Sacred do all sorts of 
> required, supporting tasks.  It is to create a protocol that 
> uses the beep 
> interface.
> 
> That, of course, means it will run over beep.
> 
> If you wish to make your new application run over OTHER 
> infrastructure 
> services, you merely need to assemble those services into a 
> package that 
> satisfies the beep services.
> 
> d/
> 
> ps.  If you can specify Sacred requirements for an 
> infrastructure package 
> of services that is different from beep, please do so and 
> then get support 
> for it.
> 
> 
> ----------
> Dave Crocker  <mailto:[email protected]>
> Brandenburg InternetWorking  <http://www.brandenburg.com>
> tel +1.408.246.8253;  fax +1.408.273.6464
>