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

Re: Everything degenerates to Key Management


gnu> If all we're standardizing is a protocol for small virtual private
gnu> networks, we're wasting the IETF's time.  Half a dozen companies could
gnu> get together and do that.  Our job is to engineer the Internet.

  In fact this has already happened!

skrenta> I'll submit that this has more to do with ACL management, i.e. the
skrenta> "naming problem", than the underlying encryption protocol.
 
  I agree with this. But, if we can not decide on what the underlying
encryption protocol is, then we can not even deploy the *simple* things
that people want to do. Thus the "groundswell" of support on the list for
SKIP. It solves these people's problems *now*. 
  The SKIP vs Oakley debate is *not* just a decision of:

# tail /etc/rc.local
	if [ -x /usr/sbin/skipd ]; then
		/usr/sbin/skipd
	fi

  vs

# tail /etc/rc.local
	if [ -x /usr/sbin/ikmpd ]; then
		/usr/sbin/ikmpd
	fi

  Rather, you have to change your kernel unless someone decides to support
both, and I do not know how the two systems will interact. I have not seen,
for instance extensions to the BSD44 socket API on how SKIP will be available 
to user processes wishing keying. (Yes, this is Unix specific, but how
many TCP/IP capable systems do *not* support some kind of BSD-like socket API?)

skrenta> Designing crypto exchanges and packet formats is comparatively easy;
skrenta> informing your machine that it's supposed to encrypt with a 
particular set
skrenta> of modes+algorithms to a particular (possibly randomly assigned) IP
skrenta> address is hard.  But insofar as a workable solution is developed, I
skrenta> believe that it should prove fairly independent of the underlying
skrenta> encryption system.
skrenta> 
skrenta> This problem is really at a different level than the SKIP vs. Oakley
skrenta> debate, since neither set of drafts speak much to this issue.

  I had hoped that the meetings would come up with a way to incorporate 
the SKIP header into the IPsec architectural draft (rfc1825). I have some 
ideas on how to do this, but I do not have enough experience with both SKIP 
and rfc1825 to do this on my own.
  If the stuff on the wire could be compatible at the "manual keying" level,
and an API similar to PF_KEY could accomodate SKIP keying, then we could
solve the other problems later. Some smart person may come up with a hybrid
solution that looks like neither solution.



-- 
      mcr@milkyway.com       |     <A HREF="http://www.milkyway.com/">Milkyway 
Networks Corporation</A>
   Michael C. Richardson     |   Makers of the Black Hole firewall 
 Senior Research Specialist  | info@milkyway.com for BlackHole questions
 Home: <A HREF="http://www.sandelman.ocunix.on.ca/People/Michael_Richardson/Bio
.html">mcr@sandelman.ocunix.on.ca</A>.