[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: definitions versus protocols



I guess I should reply to this since I am that un-named shared author of
both the RC5 and CAST128 ESP drafts.

Bill, the layout and wording of the new style ESP algorithm documents
came about from many months of discussions.  As you know we have been
moving towards Steve Kent's new template oriented ESP and moving away
from 'transforms'.  One of the major issues that I (and other people)
wanted resolved was to not have any overlapping between the main ESP
document and all other algorithm documents.  After discussions in
Memphis and several ANX bake-offs, I believed that we had enough
information to produce a half-decent first draft of what an ESP
algorithm document was suppose to look like.  The result was the RC5 and
CAST128 drafts.  

These two documents were co-written with their appropriate
representatives (Baldwin and Carter) and were sent out to various
implementers before officially submitting them to the IETF.  Steve Kent
also had some very good input to these documents.

As one of the IPSec implementers, and as having written all of the code
from scratch (i.e.. RFCs), I wanted to write a direct and to-the-point
draft that a developer would be able to quickly retrieve the desired
information and implement that cipher algorithm.  

Everything that isn't in these documents was already in the ESP draft.
I think this line from the my drafts says it all;

  "Furthermore, this document is a companion to [Kent97] and MUST be
read in its context."


That being said, these two documents are first drafts and should be
updated and are not "ready for prime time".  Thus any constructive
criticism and comments are appreciated.


Roy Pereira
TimeStep Corporation

>----------
>From: 	William Allen Simpson[SMTP:wsimpson@greendragon.com]
>Sent: 	Saturday, May 24, 1997 11:02 AM
>To: 	Bob Monsour
>Cc: 	ipsec@tis.com
>Subject: 	definitions versus protocols
>
>Thanks for the comments, especially from an implementor; but as a
>long-time participant, I cannot agree that this was the intent of most of
>the folks _I_ was talking to....  (a small group of folks reviewed the
>documents before I sent them off to the drafts repository).
>
>So, it looks like we really need a "straw poll" as to whether these
>should be merely "shims" or true protocols.  Let's debate that in this
>thread for a week (ending May 30th), and see if there's a broader
>consensus one way or the other.
>
>As I mentioned, the CAST and RC5 (sharing an author) don't provide
>enough information to write any code.  They just shim between real
>documents.  That's my objection.
>
>I have a strong prejudice for working on code, and therefore have
>principly limited my efforts to code-generating documents.
>
>If these are "algorithm/transform definitions, not protocols", then they
>would not be able to be on the Standards Track.  The IETF standardizes
>protocols, upon demonstrated interoperability.
>
>A shim would be easier to produce, but would only be an Informational RFC.
>
>
>> From: Bob Monsour <rmonsour@earthlink.net>
>> In what is being refered
>> to as the "new" ESP draft (draft-ietf-ipsec-new-esp-00.txt), the 2nd
>> paragraph of section 3.2.3.2, Encryption Algorithms, states:
>>
>>    At the time of writing, one mandatory-to-implement encryption
>>    algorithm and mode has been defined for ESP.  It is based on the Data
>>    Encryption Standard (DES) [NIST77] in Cipher Block Chaining Mode
>>    [NIST80].  Details of use of this mode are contained in [need a new
>>    I-D with DES-CBC and implicit IV generation, but no overlap with this
>>    document].
>>
>> The operative phrase is "but no overlap with this document".
>...
>
>I do not treat the old "new" ESP draft as gospel.  We've already agreed
>that it oversteps its bounds, and have more clearly defined its scope.
>My draft is based on the Memphis meeting.  We await the "new" "new" ESP.
>
>
>> Would it not have been simple to create a draft that really matched the
>> goal of matching the intentions of the "new" ESP draft and the wg? That
>> would have been a great service to the wg.
>>
>I did my best, within the limitation of my understanding of what was
>desired by the broad group of implementors.
>
>
>> At 03:27 AM 5/24/97 GMT, William Allen Simpson wrote:
>> >I looked at those (CAST & RC5), and found them remarkably uninformative.
>> >I cannot imagine a "protocol" description without packet formats.  They
>> >should put some packet formats in!
>>
>> I see these as algorithm/transform definitions, not protocols. They define
>> how to take a set of data and transform it into another set of data. The
>> context is, as stated simply and elegantly in the abstracts of the RC5 and
>> CAST drafts (and these are the only words in the abstracts):
>>
>>    This draft describes the CAST-128 block cipher algorithm as to be
>>    used with the IPSec Encapsulating Security Payload (ESP).
>>
>>    This draft describes the RC5 block cipher algorithm as to be used
>>    with the IPSec Encapsulating Security Payload (ESP).
>>
>> 	(OK, so they share an author)
>>
>> >The only true change in "new" ESP is the
>> >requirement of the sequence field in all transforms, and adding an
>> >optional trailing Authenticator.  That's all I've done here, update to
>> >match the "new" ESP environment.
>>
>> Not so. The move to the "new" ESP environment involved a conscious document
>> structure change, not just the protocol changes you mentioned. That
>> structure change is intended to simplify the specifications by eliminating
>> reduntant and potentially conflicting requirements (i.e., factoring out the
>> common elements of the packet formats and leaving the transform docs to
>> specify algorithmic details).
>>
>The decision by _Steve_ to do this was debated on the list, and I saw
>dissent.  We need a nice general ESP document, but I have always seen
>the ESP document as the template and "applicability statement", and the
>transform documents as the protocols.
>
>Clearly, you and I have a difference of vision.
>
>
>> >I don't like _under_ specifying stuff.  Each transform should stand on
>> >its own!
>>
>> B relating the transform drafts back to the base ESP draft (as you do and
>> the RC5/CAST drafts do), then they DO stand on their own as separable
>> transforms that support the packet formats as defined in ESP. They MUST be
>> read AND used in conjunction with ESP and ONLY in conjunction with ESP. If
>> you REALLY want them to stand on their own in the context of all the
>> working groups, then I would go further to say that they should just
>> describe the algorithms and not refer to any base packet formats. In that
>> way they could be referenced by any base protocol spec such as TLS or ECP
>> by way of IANA numbers. But in my relatively short IETF life, I wouldn't
>> expect to see that happen at this stage and would be grateful to fulfill
>> the intentions of the wg and the ESP draft (and for this purpose, we have
>> the IPSec DOI).
>>
>A very different vision.
>
>I am not in favor of transforms so general that they could be used
>without packet formats.  That's what the algorithm documents (like CAST
>just published as an RFC) should do.  The transforms are specific
>applications of the generic algorithms in concrete form.
>
>WSimpson@UMich.edu
>    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
>BSimpson@MorningStar.com
>    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2
>