Re: SACRED Protocol (long!)

Hi Dave,

To summarize -- you've clarified that BEEP gives us a standard way to define:

 - message types (upload, download, change password, ... message responses)
 - message framing
 - common error codes
 - etc.

BEEP also has many additional features that we don't need.  As you say, if we don't
need them, that's not problem -- just don't use them.

We're convinced there will be many constrained devices (many different suppliers,
high volume products) that will not have storage space available to add support for
much of anything.  I believe we're not as concerned about bits on the wire and cpu
overhead as long as usage is in line with what any similar protocol would use.  The
rub occurs whenever {SACRED + BEEP + SASL +...} won't fit.

Until now, BEEP is the only option that's had much list discussion.  I agree with
Magnus and others that http/SOAP should also be considered assuming it's sure to be
present in many client devices.  In fact, "ryo" should be possible if/when we
encounter a situation where a bare-bones approach is truly required.

Additional comments inline.

Best Regards,

--dg




Dave Crocker wrote:

> Dale,
>
> At 09:01 AM 12/10/2001 -0600, Dale Gustafson wrote:
> >As it's currently defined, the base SACRED protocol is fairly straightforward:
> >
> >  - Mutually authenticate client and server,
>
> A function that SASL already performs
>
> >  - dynamically negotiate a strong encryption key (session key) known only to
> >client and server,
>
> A function that SASL already performs
>
> >  - client sends in a single request message (encrypted with session key),
> >  - server returns a single response message (encrypted with session key).
>
> Functions that require some infrastructure, above TCP and below the SACRED
> semantics.
>
> No matter how few or simple the interactions.
>
> >It appears that BEEP is aimed primarily at simplifying and accelerating the
> >design and implementation of sophisticated application protocols.
>
> Primarily?  Sophisticated?  No and No.
>
> All applications need framing and error codes and basic mechanisms for
> exchanging things.  BEEP standardizes these.  If you do not use BEEP, you
> must (re-)invent some other method of performing them.

Yes, every application that doesn't use BEEP must do something like that.

> Negotiating options, such as SASL, is typically required.  Again if you do
> not use BEEP, you must re-invent them.  However if an application does not
> need negotiation, the cost of it is not incurred.  For SACRED, it appears
> that SASL can solve some standard requirements in a standardized way.  Why
> anyone would want to re-invent mechanisms that are a) already working well,
> and b) difficult to design and deploy successfully, is a matter of some
> curiosity and should be a matter of very great concern.

Agree, althought it's not as clear that SASL needs to be tightly coupled with BEEP.

Also, many SASL mechanisms won't work for SACRED.  Ideally, we need a proper subset
of SASL.

> The multiplexing mechanism of BEEP is a different matter from the
> others.  It is somewhat innovative (or at least unusual), not simple enough
> to call trivial, and does not yet have large amounts of operational
> experience.  So it is nicely convenient that if you do not need its
> benefits, you do not incur its costs.  On the other hand, if you DO need
> those facilities, you should be eager to avoid re-inventing them, since
> they are known to carry significant risk.
>
> The bottom line, therefore, is that the BEEP method of performing
> particular functions adds essentially no overhead to a protocol that needs
> those functions.  And for protocols that do not need particular BEEP
> sub-functions, BEEP adds no overhead at all.
>
> The only question, therefore, is where the pieces come from.  They can come
> from a standardized place, like BEEP, or they can be
> re-invented.  (Re-)inventing mechanisms -- even very small bits of
> mechanism -- carries far more cost and risk than is generally
> appreciated.  What is small and simple and easy for an individual developer
> is different for an Internet-scale effort.  Internet efforts are always
> large, expensive and risky.  (For those so inclined, think of it as the
> difference in cost between engineering a product vs. total life-cycle cost
> for the product, and in risk between building something simple vs. ensuring
> that the business selling it is successful.)
>
> The premise behind BEEP is that using BEEP saves the community considerable
> effort/cost and reduces risk.  Again, let me caution that we distinguish
> between an individual's perspective on effort and risk, versus the
> community view.  Most people do an analysis in personal terms, rather than
> knowing or thinking about community-level issues.
>
> > The SACRED request-response protocol seems to be a relatively poor fit for
> BEEP's

> >capabilities
>
> On the contrary, it seems like an excellent fit, as noted above.

> >A dominant techical factor affecting the SACRED protocol is that it will often
> >be used with highly constrained client devices.  It may not yet be clear
> >to many how much that technical factor tends to overwhelm others.
>
> Perspective on "highly constrained" changes over the years.  From an
> historical perspective, the idea that anything that is considered highly
> constrained would use HTTP is, in fact, downright amusing.

Highly constrained means a ROM or EE-PROM based appliance such as a cell phone or
similar device.  Typically, room for new functionality must be found by replacing
and/or compressing existing functions (which can often be very hard work).  Pent up
demand for additional application functionality complicates things ...

The reason that http may well emerge as the top candidate is solely by virtue of
the fact it's already a "must support" capability in most applicable client devices
since they depend on http to provide much of their internet functionality.  We
will, no doubt, need the flexibility that allows us to take a free ride on well
known capabilities whenever necessary.

> Less frivolously, I challenge the claim that BEEP somehow introduces
> significant overhead, beyond that inherent in the functions it
> performs.  That is, for the substructure functions that SACRED needs to
> perform, I challenge that they can be performed with massively less
> overhead than BEEP incurs.

Don't think that BEEP introduces any unusual processing or protocol overhead.  In
any event, reasonable additional overhead is probably not a big issue.

However, using an extra 2 or 4 K of a client device's storage space might be a
non-trivial problem (seems strange, I know).

> The one point of debate might be default data encoding, since MIME and XML
> are not maximally efficient.  This issue is a matter of long-standing
> debate in the applications protocol community, and has generally
> demonstrated preference and success for text encoding.
>
> >I think it's easier to see that Magnus'
> >conclusion that it's preferable to include all functions described above
> >within
> >the SACRED protocol (e.g., sooner rather than later) is probably unavoidable
> >and, most importantly, it would be significantly less painful to establish
> >such
> >a structure now.

> It always seems better to create a fully self-contained facility.  For
> Internet design, the history is that it is not only NOT better, but in fact
> it is just plain wrong.

We're after the most flexible standardization structure that fits a very wide range
of needs.

< snip  >


>
> d/
>
> ----------
> Dave Crocker  <mailto:[email protected]>
> Brandenburg InternetWorking  <http://www.brandenburg.com>
> tel +1.408.246.8253;  fax +1.408.273.6464