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

RE: "Transforms" per se going away?



Daniel Harkins wrote:
>
>>Dan McDonald wrote:
>>> *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.  
>
>>[example snipped]
>
>>> 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.)
>
>>It will change many working ISAKMP implementations which also put bits on
>>the wire in a well-defined manner. Doing away with the transform and making 
>>everything an attribute will change existing payloads and the way payloads 
>>are constructed and processed. Not that this is necessarily a bad thing, 
>>just that these changes are not completely editorial and everyone needs to 
>>understand that.

We shuold make every effort to maintain backwards compatibility with the
current transforms, but in the future we should be looking at moving
away from the "Transform" concept.  For IPSEC-DOI, we could create a
TRANSFORM ID that allows us to define the transform's parameters (cipher
alg, hash alg, replay, ...) all in attributes instead of having the
transform identifier specify which parameters.  This way we do not have
to write hundreds of transform RFCs for every possible combination of
parameters.

Example:
	ISAKMP Transform Payload:
		Transform ID: TRANSFORM-ALA-CARTE
		Attribute 1: Cipher Alg: 3DES
		Attribute 2: Hash Alg: SHA1
		Attribute 3: Keyed Alg: HMAC
		Attribute 4: Replay Protection: 32-bit