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

Re: SKIP in IPSEC: is it really simple?

> How do you plan to handle certificate expiry without shared time?

There are many different grades of shared time out there.

I don't think you need NTP-grade shared time (or even kerberos-grade
shared time -- ~5minute accuracy) to enforce expirations of
certificates which last over a month ...  getting the day right is
probably good enough.

By the way, when engineering timeouts and grace periods, you also have
to think about clock frequency errors, network latency, and processing
latency in addition to absolute accuracy.

I butted heads with this issue when doing the DCE RPC security
protocol (though for that, we do require shared time).  In the general
case, you don't *ever* want to send a packet which the reciever will
reject because the SPI just expired.

SPI timeouts should probably be expressed with a relative TTL after
which the sender should not send to the SPI; the receiver should
continue to honor packets received on the SPI for a (short) grace
period after the published TTL expires, the grace period being a
function of the TTL (to allow for clock frequency errors) and the
worst-case end-to-end latency between the systems..

						- Bill


To: Rich Skrenta <skrenta@osmosys.incog.com>
Cc: ipsec@TIS.COM
Subject: Re: Using SKIP as inspiration, not as gospel 
In-Reply-To: Your message of "Thu, 12 Sep 1996 10:17:32 PDT."
             <199609121717.KAA18752@miraj.incog.com> 
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Thu, 12 Sep 1996 14:54:34 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID:  <9609121513.aa28910@neptune.TIS.COM>


Rich Skrenta writes:
> The fact that the SKIP camp is not willing to open up a solidified, mature
> design to rewhack it into something that looks just like Photurus does not
> make us "hamstrung".  To suggest that we change SKIP to make it "more like
> every other key management protocol" misses the point of this entire
> debate.

Rich;

Other people don't think of SKIP as a solidified, mature design.

To many of the rest of us, it is very unclear that SKIP has any
advantages over other protocols -- the claims to the effect that it is
lower overhead are illusory.

Some of us don't like the fact that SKIP does not play nicely with the
IPSec model. It has improved in certain respects with respect to the
requirements, but the fact remains that it just isn't, to many of us,
what the doctor ordered.

You and everyone else at Sun's Internet Commerce group are necessarily
going to disagree, I'm sure. I don't think this is going to be
resolved by discussion. I believe that intransigence has definitively
set in.

Perry



Message-Id: <199609121907.MAA21082@denwa.incog.com>
X-Mailer: exmh version 1.6.4 10/10/95
To: HUGO@watson.ibm.com
Cc: skrenta@osmosys.incog.com, ipsec@TIS.COM
Subject: Re: SKIP in IPSEC: is it really simple? 
In-Reply-To: Your message of "Thu, 12 Sep 1996 12:03:11 EDT."               
 <199609121619.MAA529798@mailhub1.watson.ibm.com> 
X-Url: http://www.incog.com/~stoltz
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 12 Sep 1996 12:07:26 -0700
From: Ben Stoltz <stoltz@denwa.incog.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk



HUGO@watson.ibm.com said:
> My personal vote here is against co-existence. That will postpone 
> global success (inter-operability) even more. There will be time to 
> tune the one chosen protocol later with experience. But there should 
> be one basis for all.
>
> Hugo

Although the decision of IPSEC is important, I don't think
it will have the effect that you desire. IMHO, each of the IPSEC
proposals have gone past the point of being buried or marginalized.
Additional IPSEC requirements are going to come into being through
evolution of the existing implementations. Even if IPSEC completely
drops one proposal, the installed customer base will need to be
migrated to the final IPSEC implementation and many existing and
new customers will find substantial value in the original product
offerings.

People seem to be burning a lot more calories arguing and fretting
over these "issues" than is healthy. What if the argument were
"Should we implement TCP or UDP?", "Should we implement IPX or IP?",
"Should we manufacture cargo planes or box cars?", "Run Windows NT or
MVS or maybe even Unix?" For any single customer there might very well
be a correct answer, but would be a real feat if it applied to all.
A single standard is a beguiling goal, but it is not always relevant
or as economical as it may seem. Swiss army knifes are great, but
if I spend all my time driving nails, I don't need one.

 Ben
References: