[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC WORKING GROUP LAST CALL
From: "Ramesh Kamath" <ramesh@redcreek.com>
Date: Thu, 19 Feb 1998 11:11:58 -0800
The latest Feb 16 1998 draft-ietf-ipsec-ipsec-doi-07.txt, does not have
definitions for 40 Bit DES and 3DES 112 bit, in IPSEC ESP transform
identifiers.
40 Bit DES isn't currently defined in a cipher suite algorithm anywhere,
so I'm not particularly saddened or disturbed by its omission. ESP_3DES
is defined (it has the value of 3) and that is a 112 bit (3key) triple
DES. See draft-ietf-ipsec-ciph-3des-00.txt. So, I don't believe either
of your concerns is a problem. Your question about triple DES does
another one, though, which I will put to the working group:
The triple DES document wasn't one of the documents that I put into IETF
last call, as one of the "core group" of documents. Do people believe
that should get pushed out to the IESG at the same time?
There is a related question to the other cipher suites for which DOI
document contains references: ARCFOUR, Blowfish, and RC5. Since RFC's
are not allowed to refer to internet-drafts, what do we want to do with
them in the DOI spec? There is also a reference in the DOI draft to
draft-mcdonald-pf-key-v2-03.txt (and the latest version of that I-D is
-04).
Our choices for each referenced I-D include (a) deleting the reference
from the draft, or (b) advancing the I-D along with the main set of
documents. Note that if we choose (a), it's no big deal; we would
simply move the DOI assignment to the (delayed) cipher draft, and when
the cipher draft advanced, it would get added to the IANA's registry
list.
The advantage of (a) is that it might speed up the time that it takes
the IESG to the IPSEC drafts, since it won't have to deal with the extra
drafts. It also means we don't have to take time now vetting these
"non-core" drafts (which I suspect most people haven't paid much
attention to at this point). The advantage of (b) is that for people
who really want to use these other algorithms, they will be available
sooner, and the DOI would contain a slightly more comprehensive list.
My tendency is to lean towards (a) for all of the non-core cipher
documents (except possibly triple DES), but I'm certainly willing to
hear arguments to the contrary, or for other alternatives.
As for the reference to the PFKEY API, we can either (a) remove the
reference, or (b) suggest that this be advanced to informational,
assuming that the PFKEY folks believe that the document is stable. The
reference doesn't appear to be in a critical part of the text, so it
probably isn't a big deal to remove the reference if the PFKEY spec is
still undergoing revisions.
Comments?
- Ted
Follow-Ups:
References: