[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: