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

Re: AH and ESP othogoanlity

ASIDE:
	I'm deliberately ignoring the notes to the IPsec list that focus on
"history" or "personal issues" rather than technology.  My silence does NOT
imply that I agree with others' views of history or that I agree with the
words that others are putting in my mouth.  Mainly, I'm focusing on writing
IP code.  I prefer writing IP code to playing rhetorical games with history
or personal issues.

In article <9603121331.AA17052@MAILSERV-H.FTP.COM> Naganand wrote:
>I agree that there are merits performing integrity along with encapsulation.
>The only problem I see with it is that there will be deployments for IPSEC
>in the very near future and most of the the implementations have implemented
>RFC's 1828 and 1829. We definitely cannot stop this as many customers have
>been asking for it.

	I don't think anyone has suggested that anyone stop deploying those
transforms, though it seems likely that at least RFC-1829 will move off the
standards-track to Historic status eventually.  It might later become the
case that some new transform would be mandatory-to-implement in lieu of
RFC-1829, but this could be addressed by adding support for an additional
transform whilst not removing support for the RFC-1829 transform -- if an
implementer chose to do such.

>This may cause configuration problems for old implementation (implementing
>only 1829) to interoperate with the newer implementation which may support
>both 1829 and the new transform. Can we allocated numbers to the transforms
>as most of the key management protocols do so that configuring with manual
>keying is simplified?

	I believe that more or less any publicly documented transform
should be allocated its own "transform identifier" by each of the various
key management proposals.  I specifically asked the ISAKMP authors to add
transform identifiers for the current Experimental transforms so that nodes
that choose to use those transforms can use ISAKMP for key mgmt.

NOTE: I have not fully grok'd Perry's anxiety over the word "replace" and
don't want to get into that here and now because it doesn't seem terribly
productive here and now.

	I will note that in my view if RFC-1829 were replaced on the
standards-track by an ESP DES-CBC+MD5+Replay transform, this would mean
that the replacement ESP DES-CBC+MD5+Replay transform would be allocated a
new "transform identifier" (i.e. transform identifier that is different
from the one that would remain allocated for RFC-1829).  I use "replace" in
the context of what the mandatory-to-implement transform would be rather
than in the context of what is meant by a particular "transform identifier"
number.

	This is just a matter of good protocol engineering.  If a transform
changes in a material way, then it needs a new published specification and
it needs a new "transform identifier".  We will probably continue to add
new and better transforms forever in the future as technology advances.
Implementers who don't design/build with the assumption that new transforms
will eventually come will probably regret it later on.

Bottom Line:	Naganand and others with similar concerns should not
		worry about this particular issue.  Key mgmt draft authors
		should allocate transform identifiers for each stable
		openly-published transform (An Internet-Draft is, by
		definition, not considered stable but an RFC is stable).

Ran
rja@cisco.com
References: