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

Re: definitions versus protocols



> From: "William Allen Simpson" <wsimpson@greendragon.com>
> 
> 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.
>
> [...]
> 
> 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.


Since we are straw polling, I absolutely agree with Bob M. that the
ESP document should be the protocol definition and that the transform
documents should be orthogonal to the ESP specification.

 * This is good engineering practice - using the ESP document as
   a boilerplate template to derive standalone transforms is just begging
   for mistakes to creep in, both in the document editing stage and in the
   implementation stage.  If you don't have redundant specifications,
   you can't have inconsistencies between the redundant copies.  (You can
   still have mistakes, but you only have to fix them once.)

 * If all transform documents include copies of ESP, changes to the ESP
   protocol (bits-on-the-wire, or changes in interpretation of existing
   bits) would require reissuing *every* transform RFC, even if the ESP
   changes had no algorithm-specific component (example: change to the
   size of the AR counter).

 * Although IPSEC is the first consumer of the transform documents and
   IPSEC should be the focus of this working group's effort, I believe it
   is valuable to write the algorithm definitions in such a way that they
   could be referenced by other protocols (TLS, S/MIME, ...) if other
   working groups choose to do so.  Including only algorithm-specific data
   in the transform documents facilitatates such reuse.

 * The IETF is not the ISO, where one must wade through endless chains of
   references, some of which may be difficult to obtain.  RFCs are all
   available in one place, and implementors should find it no more difficult
   writing code from a single ESP specification and the algorithm-specific
   supplements than from standalone algorithm documents.  In the case of
   multiple-algorithm implementations, I contend that the orthogonal
   approach makes the implementor's life easier.