[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

"Transforms" per se going away?



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         +


Follow-Ups: