"Transforms" per se going away?
Dan McDonald <Dan.McDonald@eng.sun.com> Thu, 13 February 1997 00:16 UTC
Received: from cnri by ietf.org id aa26990; 12 Feb 97 19:16 EST
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa24174; 12 Feb 97 19:16 EST
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA00767 for ipsec-outgoing; Wed, 12 Feb 1997 19:03:10 -0500 (EST)
From: Dan McDonald <Dan.McDonald@eng.sun.com>
Message-Id: <199702130007.QAA28204@kebe.eng.sun.com>
Subject: "Transforms" per se going away?
To: ipsec@tis.com
Date: Wed, 12 Feb 1997 16:07:09 -0800
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
While I hate to interrupt the replay-field size discussion, I have something else that needs to be brought to the attention of the general IPsec mailing list. While discussing the next round of PF_KEY tweaks, something I thought was common knowledge apparently is not. This may also explain why we haven't seen updates on ISAKMP, IPsec DOI, and other goodies yet. Anyway, lemme quote the text > By the way, if transforms are going away somebody should alert the ISAKMP > folks and Derrell Piper (IPsec DOI author). The transform payload has a > "transform id" entry (using a transform number from the DOI doc) and > attributes of that transform. The way the documents are now, ISAKMP > negotiates a transform (DES-CBC-HMAC-MD5-REPLAY) and approriate attributes > (e.g. lifetime), not a jumble of attributes (DES-CBC, lifetime, HMAC-MD5, > etc). *I* was under the impression that with the next round of base document updates, the IPsec headers would move away from the "transform" concept, and into a "pick an item off the checklist" concept. For example: For ESP Pick One from each category: Encryption: (DES/3DES/IDEA/RSA/rot13/...) Authentication: (HMAC-MD5/HMAC-SHA/none/HMAC-CRC8/...) Replay? (Yes/No) Replay size (May be a moot point...) [NOTE: There is no "none" for Encryption in ESP. This is why we have AH. Remember, some of us have to deal with export control bullsh*t.] For AH Pick One from each category: Authentication: (HMAC-MD5/HMAC-SHA/HMAC-CRC8/...) Replay? (Yes/No) Replay size (May be a moot point) Pad to 8bytes? (Yes/No) PLEASE NOTE RIGHT NOW THAT THIS WILL NOT CHANGE THE BITS ON THE WIRE WHICH ARE ALREADY WELL-DEFINED, AND WORKING IN MANY PEOPLE'S CODE! (Pardon my shouting, that's a very important property though.) So if this is the direction we're indeed heading, we should make this clear sooner rather than later, because certain docs (ISAKMP, IPsec DOI, PF_KEY, and any Advanced BSD API work) will need to take this into account. Speaking as an implementor of IPsec in my kernel, I like the concept of the checklist, as I can make kernel-loadable _authentication_ modules and kernel-loadable _encryption_ modules. The former I can actually just attach to AH and ESP w/o tweaking separate ESP and AH versions. Any comments folks? Sorry to ruin your week with something like this. I'd much rather be writing more code myself, but this seemed important. -- Daniel L. McDonald | Mail: danmcd@eng.sun.com Phone: (415) 786-6815 <*> + Software Engineer | *** My opinions aren't necessarily Sun's opinions! *** | Solaris Internet | "rising falling at force ten | Engineering| we twist the world and ride the wind" - Rush +
- "Transforms" per se going away? Dan McDonald
- Re: "Transforms" per se going away? Daniel Harkins
- RE: "Transforms" per se going away? Roy Pereira
- Re: "Transforms" per se going away? Stephen Kent