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

Re: bandwidth in the Internet

In message <Pine.SOL.3.91.960910152508.13213C-100000@rafael.border.com>, Norman Shulman writes:
> On Tue, 10 Sep 1996, C. Harald Koch wrote:
> 
> > Increasing the ACK size to 65 bytes (20 for SKIP+ESP?) yields 660Kbps
> > throughput on the forward channel; even worse.
> 
> I figure a throughput of 1.32 Mbps; not so bad.

Oops, forgot to multiply by 2 for acking every *second* segment. I guess
that destroys what's left of my credibility... <grin>

-- 
Harald Koch
chk@border.com

From: Dan McDonald <danmcd@pacific-86.eng.sun.com>
Message-Id: <199609102010.NAA04270@kebe.eng.sun.com>
Subject: Re: Everything degenerates to Key Management
To: ipsec@TIS.COM
Date: Tue, 10 Sep 1996 13:10:06 -0800 (PDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

<NOTE:  This is a retransmit.  I haven't seen this note and it's been 24
hours.  --  Dan McD.>

This is in reply to a note sent a bit back by Michael Richardson.

<SNIP!>
> 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*. 

SKIP is not an "underlying encryption protocol."  It is a method of
transmitting the cryptographic keys so that encryption and decryption can
take place, hence the term "key management."

>   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?)

Network API extensions for having users turn on IP-level encryption or
IP-level authentication haven't been thought out, from what I've seen.
GSS-API may be useful in such a context, but I found the sheer bulk of it
intimidating.  The NRL IPv6/IPsec code has a _very_ primitive API for
requesting security services.

The above paragraph and its issues are ORTHOGONAL to what key management
strategy is used.  It doesn't matter if you implement one, the other, or both
(and you CAN implement both, see below), it's still an issue.

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

By that, if you mean setting up what ESP/AH algorithms are preferred, perhaps
what ESP/AH algorithms are REQUIRED for communications on that machine, yes,
it's a different level.  It's called POLICY, and policy and mechanism are
separate.

If you mean what ESP/AH algorithms and modes can be used between a (possibly
randomly assigned) IP address and me, there are already solutions for this.
SKIP has its {Certificate, Algorithm} Discovery protocols, and the whole idea
behind ISAKMP is that these very parameters are NEGOTIATED between the two
machines before a session begins.

Speaking of certificates, and problems orthogonal to key management debates,
here's something I have to ask.  _Regardless_ of key management, is it not
true that each security endpoint is defined by the certificate associated
with it?  If so, this may answer questions about "user oriented" or whatever
buzzwords you want to use to state that IPsec keys should be unique per
session.

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

I have plenty of experience with RFC 1825, and being where I am, I am quickly
learning about SKIP.  Quite frankly, I'm surprised nobody else has thought of
the idea of having a "SKIP transform" that fits the relevant SKIP header
information INSIDE a vanilla ESP or AH header.  Quite frankly, in
highly-modular environments (such as my current one), I can win big in
implementation, because I have MUCH MORE control over the interface between
transforms and ESP/AH, than I do between putting yet another higher-level
protocol on top of IP.  This control I mention allows better optimization and
other code-reuse issues.

In a not-so-modular environment (i.e. BSD) it's a wash, 6 one, half dozen the
other.

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

I have thought quite a bit about how PF_KEY could be made to accomodate SKIP
keying.  Particularly, the SKIP Kij keys could be computed in user-land, and
fed into the kernel via PF_KEY, where they are used for the SKIP packets
flowing across the wire.  This also means you can build {Cert, Alg.}
discovery in user-space as daemons.

Unless I'm totally wrong about PF_KEY being able to work with SKIP, then it's
VERY FEASIBLE to build SKIP, Oakley, and Photuris into the same box.  More on
this after I explain in-band vs. out-of-band...

As for the stuff on the wire being compatible, the big difference between
SKIP and your choice of Photuris or Oakley is that SKIP is in-band keying,
where the session key is part of the packet (cryptanalysts, take note), and
that both Photuris and Oakley are out-of-band keying, where an exchange
(authenticated exchange, I hope :) takes place before data squeezes out of
the wire.  This difference in approach makes compatibility hard.

Now that I've explained that, if you have PF_KEY that works, you can build
ARBITRARY out-of-band keying systems.  And with your favorite in-band keying
system being implemented in-kernel (i.e. SKIP), you have a system that
addresses ALL of your key management needs.

Manual keying, BTW, is part of RFC 1825.  I should be able to manually
configure an SPI, with the relevant keying information.  Tom Markson at
Montreal mentioned that the latest SKIP release for {FreeBSD, SunOS 4.1,x}
supports manual SPI's per RFC 1825.

I hope this adds useful implementation-oriented data to the discussion.

--
Daniel L. McDonald | Mail: danmcd@eng.sun.com   Phone: (415) 786-6815        +
Software Engineer  | *** My opinions aren't necessarily Sun's opinions! ***  |
SunSoft Internet   | "rising falling at force ten                            |
        Engineering|  we twist the world and ride the wind"  -  Rush         +