"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         +