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