[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-simpson-esp-des1-v2-00.txt to Draft Standard
Bill,
While the wg and doc editors have been struggling to get the document
structure "cleaned up", I respectfully submit that the two drafts you
recently submitted appear to subvert that effort. 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".
While I understand that you believe that it's important for the
algorithm/transform documents to repeat certain field definitions from the
base ESP document, in this case I find it couter-productive and prone to
inducing errors. Let's take an example from from your DES draft
(draft-simpson-esp-des1-v2-00.txt) and compare it to the "new" ESP draft
and RFC1829. It states:
Padding zero or more octets.
Prior to encryption, this field is filled with a
series of integer values (beginning with zero), to
align the Pad Length and Payload Type fields at the
end of an eight octet boundary (counted from the
beginning of the Payload Data).
After decryption, it is examined for a valid series
of integer values.
This field is opaque. That is, the value is set
prior to encryption, and is examined only after
decryption.
In the "new" ESP draft (section 2.5) padding is defined as follows:
The Padding bytes SHOULD be initialized with random data and they are
transmitted. The transmitter can add 0-255 bytes of padding. Padding
beyond that required for encryption algorithm blocksize alignment may
be used to conceal the actual length of the payload, in support of
traffic flow confidentiality. However, inclusion of such additional
padding has adverse bandwidth implications and thus its use should be
undertaken with care. The Padding field is optional, but all
implementations MUST support generation and consumption of padding.
Lastly, RFC1829 states:
Padding
The size of this field is variable.
Prior to encryption, it is filled with unspecified implementation
dependent (preferably random) values, to align the Pad Length and
Payload Type fields at an eight octet boundary.
After decryption, it MUST be ignored.
I don't understand how someone can write code to support the padding
requirements that conform to RFC1829 or the "new" ESP and find that it will
interoperate with code that is written to follow your new draft. An RFC1829
programmer will send the "preferably random" values in for padding and the
implementor of your new draft will reject the incoming packet for lack of a
"valid series of integer values". While you don't say exactly what to do in
this case, it certainly leaves room for various interpretations (read that
as potential interoperability problems).
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.
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).
>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).
[To the doc editors and co-chairs, if no one is preparing drafts of DES and
3DES for use with the "new" ESP (similar in construct to the RC5 and CAST
drafts), I volunteer to take on the task as long as I get some volunteers
to review them prior to posting to double-check them.]
Regards,
Bob Monsour
rmonsour@hifn.com