Re: bandwidth in the Internet
"C. Harald Koch" <chk@border.com> Tue, 10 September 1996 19:40 UTC
Received: from relay.hq.tis.com by neptune.TIS.COM id aa01799; 10 Sep 96 15:40 EDT
Received: by relay.hq.tis.com; id PAA18078; Tue, 10 Sep 1996 15:43:32 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma018068; Tue, 10 Sep 96 15:43:09 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA18757; Tue, 10 Sep 96 15:42:17 EDT
Received: by relay.hq.tis.com; id PAA18059; Tue, 10 Sep 1996 15:43:03 -0400
Received: from mail.border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma018049; Tue, 10 Sep 96 15:42:58 -0400
Received: by janus.border.com id <18443-1>; Tue, 10 Sep 1996 15:43:43 -0400
Message-Id: <96Sep10.154343edt.18443-1@janus.border.com>
To: Norman Shulman <norm@border.com>
Cc: ipsec@TIS.COM
Subject: Re: bandwidth in the Internet
References: <Pine.SOL.3.91.960910152508.13213C-100000@rafael.border.com>
In-Reply-To: norm's message of "Tue, 10 Sep 1996 15:28:47 -0400". <Pine.SOL.3.91.960910152508.13213C-100000@rafael.border.com>
From: "C. Harald Koch" <chk@border.com>
Date: Tue, 10 Sep 1996 15:45:04 -0400
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
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 +
- Re: bandwidth in the Internet Ran Atkinson
- Re: bandwidth in the Internet C. Harald Koch
- Re: bandwidth in the Internet Paul Ferguson
- Re: bandwidth in the Internet Norman Shulman
- Re: bandwidth in the Internet C. Harald Koch
- Re: bandwidth in the Internet Phil Karn
- Re: bandwidth in the Internet Phil Karn