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

Re: (IPng) Proposed Standard or no?




Ashar Aziz says:
> 
> 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. 
> 

Actually, I have no opinion on whether IPSP can or cannot support
SKIP. At Toronto, you said that there was no problem in changing your
packet format to match IPSP. At San Jose, you didn't indicate that you
had a problem with the packet format.

After Bill Simpson made it clear that the amount of time left for
comments was limited a couple of weeks ago, you first mentioned this
need to convey key management information inside IPSP packets and you
asked if we could structure SAIDs. You never said you wanted that
before. If you did say so, it isn't in the archives of the mailing
list I just searched, and it isn't in any of my notes from the meetings.

> I have since the Toronto meeting asked for in-band key-mgmt.

"In Band" is an ambiguous term. What we are talking about is sending
key management data in IPSP packets with special reserved SAIDs
instead of in their own packets -- nothing more. My recollection is
that you said that you had no problem with IPSP on several occassions.

> 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

Yeah; they had a patented high speed hardware DES chip that took the
key at the head of the data to be decrypted, so it gave them a nice
market advantage.

> and we had some real engineering concerns that led us to do
> something similar.

> 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. 

I'm not aware that we are precluding any viable option -- including a
slightly modified SKIP. What we are precluding is pre-assigned SAIDs
and all the kernel muck that would be associated with processing them.

Perry


Follow-Ups: References: