[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (IPng) Proposed Standard or no?
> From: "Perry E. Metzger" <perry@imsi.com>
> The topic boils down to this: do we want to permit for conveying key
> management information in IPSP packets instead of in, say, separate
> UDP packets. The argument being made on our side is "it won't give you
> any performance and messes up a very clean design, making it far
> harder to implement for negligible gain". The argument on their side
> boils down to "we get to save a whole packet at the beginning of each
> of your TCP sessions, and it means you get to rekey on every packet!"
> Neither of these particularly seem to be important to me.
>
> In the end, this comes down to whether you feel SKIP should be the key
> management protocol we use -- the changes are being requested purely
> to support SKIP, because Ashar seems to have painted himself into a
> corner in which he assured us all along that he could adapt SKIP to
> the proposed IPSP design and then realized only in the last week (it
> seems) that he needed functionality at the IPSP layer that wasn't
> available.
Perry,
As I have mentioned repeatedly (and as others have also mentioned),
SKIP is not the only approach that uses in-band communication
of keys. The reason I asked if IPSP could support SKIP is because
there was some ambiguity of what can and cannot be in IPSP. Ran
and you believe that the current IPSP doesn't support it, whereas
Bill Simpson though that it wasn't precluded.
No, it doesn't in the end come down to whether you feel SKIP
should be the key-management protocol we use. The changes accommodate
key-management techniques that have nothing to do with SKIP. It
comes down to whether SKIP (or, e.g. DEC style key-management)
can be an *option* to consider later on. Precluding particular
styles of key-mgmt when we haven't yet decided on which key-mgmt
technique to use is not a good idea.
I have since the Toronto meeting asked for in-band key-mgmt.
It was in both my presentations (independent of SKIP) and this was
on a slide that was put up on the projector in both talks (despite
claims to the contrary). Check out the "Precursor to SKIP" slide that
gives a picture of in-band key-mgmt, and states that IPSP
should support this mode of operation. The Toronto slides
should still be ftp available from ftp.network.com, and if
you have hard copies from the San Jose talks it should be in
there.
This is not something that I came up with in the last few weeks,
and it shouldn't be presented as such. This doesn't lock us
into any one kind of key-mgmt and it shouldn't be presented
as such.
And please don't trivialize the argument to saving one packet in
the beginning of a TCP connection. The DEC folks had sound engineering
reasons for doing in-band key-mgmt and we had some real engineering
concerns that led us to do something similar. These issues/concerns
have been presented before, are in the slides, in the mail archives,
and don't need be rehashed over and over.
I agree with Russ, Dan, Jim, Tom, Piper, Bob Moskowitz and
others who believe that we shouldn't be precluding any viable
kind of key-mgmt option.
Regards,
Ashar.
Follow-Ups: