[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
Follow-Ups: