Re: SACRED Protocol (long!)

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.

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.

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.

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.

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 stucture 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.



At 11:37 AM 12/10/2001 -0500, Linn, John wrote:
>  Relative to most applications, SACRED is quite
>a special case.

Every application is special.

What are the specific technical or operational aspects of SACRED that make 
it unique?  I am hoping that there is more than you cited in your note.


>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)

OK.  That means you do not need BEEP's asynchrony.  So, don't use it.


>, but other applications where SACRED might be
>incorporated as an element will probably establish their transport choices
>against their own priorities and constraints.

There is a fascinating effect caused by creating a separate 
"layer":  People often tend to think that because it is separate it is 
extra or different, whereas tight integration automatically makes things 
cleaner, simpler, and/or more efficient.

That thinking is quite simply wrong.

Somethat that I create is more familiar to me than something I get from 
elsewhere.  However the fact of familiarity does not have any relationship 
to quality, ease or cost, no matter how wonderful I might think my own 
creation.

d/


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


d/

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