[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Status of IPSEC Key Management
In article <199609092151.RAA00478@thunk.orchard.medford.ma.us> you write:
>SKIP-style in-band keying is good because it doesn't add more
>round-trips.
That's not necessarily true. The general SKIP case requires: 1) Certificate
Discovery Protocol, two messages; 2) Algorithm Discovery Protocol, two
messages; and, if PFS is desired, 3) the PFS extension, two more messages.
A total of 6 messages required-- 4 if PFS is not desired. (Also note that CDP
is UDP-based, and ADP is ICMP-based requiring key managment in three places).
Oddly enough, ISAKMP+Oakley with PFS using "Aggressive Mode" also requires
6 messages; "Main Mode" with PFS requires 9 messages. Since certificates can
be piggybacked onto a normal ISAKMP payload no discovery is necessary;
ISAKMP+Oakley is one single key managment solution, not three.
It should also be noted that SKIP PFS and no pre-cached state requires
2 Diffie-Hellman exponentiations-- once to compute g^xj and again to compute
g^ij. The expense of these (in CPU as well as wall clock terms) will greatly
outweigh the cost of a few messages. And, as you noted earlier, SKIP PFS does
not provide PFS for identities.
Just as SKIP implementations can cache state for optimization (for example,
cut down the number of D-H exponentiations for PFS), so can ISAKMP+Oakley. An
ISAKMP+Oakley implementation can create N SAs with a single key management
session and cache these for future use in the Key Engine. When a new SA is
needed, one of these "larval" SAs can be used directly. Since locality holds
for most IP traffic this optimization will be quite practical. The ability
to reserve a block of SPI-space at a time will also work well with RSVP.
> It's bad because it involves extra overhead on each
>packet.. SKIP's 20-28 bytes/packet (assuming 8-16 byte traffic keys)
>adds ~50% to the size of a TCP ACK.
It also renders the SPI useless which makes RSVP support difficult (and
calls into question full compliance with RFC1826 and RFC1827 since it is
the MKID + IP address, not the SPI + IP address, that identifies state).
The multicast extension also doesn't scale well to highly dynamic multicast
groups (unicast request/response for every member to group owner to obtain
GIK).
> Has anyone (other than me) considered a scheme whereby in-band
> messages are used to set up a SA, and thereafter omitted from the
> packets?
>
> One way to do this would be to include fields saying "respond to this
> on SPI <NNN> until <expiration>" in the in-band-keying header; once an
> explicit SPI had been set up between peers, the in-band header would
> not be used.
>
> This would add ~8 bytes to the in-band keying header (assuming a
> 4-byte reply SPI, and a 4-byte lifetime).
>
> For a typical TCP exchange, the in-band keying headers would piggyback
> on the SYN and SYN/ACK packets, and then be absent from subsequent
> traffic.
This is a very interesting idea. I floated a variant on this scheme in the
key management design group. It lacked the "respond to this on SPI <NNN>"
though and instead just established a SA for SPI one. Your idea seems much
more practical.
Dan.
Message-Id: <199609101550.LAA29430@jekyll.piermont.com>
To: "C. Harald Koch" <chk@border.com>
Cc: ipsec@TIS.COM
Subject: Re: bandwidth in the Internet
In-Reply-To: Your message of "Tue, 10 Sep 1996 10:47:25 EDT."
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Tue, 10 Sep 1996 11:50:19 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
"C. Harald Koch" writes:
> Ok, let me rephrase my question.
>
> How many places in the Internet is an extra 20-30 bytes of overhead *really*
> a problem? We've already inflated packet sizes with IPv6, remember? How many
> of these environments simply couldn't live with the extra overhead in
> exchange for the security benefits?
Van J's header compression takes out most of the expanded IP address
size and all the rest on slow links. It is unclear that you can do
that with the SKIP header. And yes, when you are already talking about
several hundred milliseconds RTT for an ICMP Echo Request, every byte
counts. Dialup modem pools are big business.
Perry
From: Rich Skrenta <skrenta@osmosys.incog.com>
Message-Id: <199609101556.IAA13738@miraj.incog.com>
Subject: Re: Status of IPSEC Key Management
To: ipsec@TIS.COM
Date: Tue, 10 Sep 1996 08:56:17 -0700 (PDT)
X-Mailer: ELM [version 2.4 PL24 PGP5]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> -- on the other hand, extra overhead on a
> dialup line slows your real performance considerably, and it is true
> that most of the world still is on dialup modems.
By "considerably", you mean the extra 10ms needed to send 28 bytes
at 28.8k?
I said it hadn't been an issue in our actual deployments, because we're
actually using this stuff over slow links, and the people who are using it
aren't ranking "make it faster" highly on their feedback to us. We have a
pilot with 40 employees coming into our network over Ricochet radio modems
through a SKIP encrypting gateway. The performance loss from encryption
tends to get lost in the natural slowness of the Ricochet.
Lots of folks have been bemoaning the poor, slow-bound Internet peon.
I've actually been using SKIP over a Ricochet modem for my sole access to
the inet and work from home for the past six months. I can't tell the
difference between SKIP-on and SKIP-off. I do have lots of things on
my wish-list for our current software, but optimizing bytes out of the
SKIP packet doesn't even make the list.
From: Dermot Tynan <dtynan@fws.ilo.dec.com>
Message-Id: <9609101621.AA11693@karpov.fws.ilo.dec.com>
Subject: Re: bandwidth in the Internet
To: "C. Harald Koch" <chk@border.com>
Date: Tue, 10 Sep 1996 17:21:12 +0000 (BST)
Cc: ipsec@TIS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
C. Harald Koch wrote:
>
> How many places in the Internet is an extra 20-30 bytes of overhead *really*
> a problem? We've already inflated packet sizes with IPv6, remember? How many
> of these environments simply couldn't live with the extra overhead in
> exchange for the security benefits?
Well, one of the big areas (IMHO) for security is telnet. While an
extra 20 bytes isn't too bad over FTP with a high packet size, the
average typist can end up with around 40 bytes per keystroke (in
each direction). Now add an extra 20-30 bytes and you've effectively
halved the throughput. OK, I know that no single session would notice
the loss of bandwidth if they're typing that slowly. However, attach
enough people to the network, each one sending a packet per keystroke,
and you're talking real bandwidth killers.
- Der
--
Dermot Tynan +353 91 754608
dtynan@ilo.dec.com DTN: 822-4608
Digital Equipment International BV, Galway, Ireland
References: