Re: JFK nit

Eric Rescorla <ekr@rtfm.com> Wed, 15 May 2002 16:37 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4FGbSL01429; Wed, 15 May 2002 09:37:28 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04672 Wed, 15 May 2002 11:55:35 -0400 (EDT)
To: Tero Kivinen <kivinen@ssh.fi>
Cc: danmcd@east.sun.com, ipsec@lists.tislabs.com
Subject: Re: JFK nit
References: <200205131349.g4DDnQR9029024@kebe.east.sun.com> <15586.26540.982804.447696@ryijy.hel.fi.ssh.com>
Reply-to: EKR <ekr@rtfm.com>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset="US-ASCII"
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 15 May 2002 09:09:06 -0700
In-Reply-To: Tero Kivinen's message of "Wed, 15 May 2002 16:50:36 +0300"
Message-ID: <kjlmal1jh9.fsf@romeo.rtfm.com>
Lines: 27
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

Tero Kivinen <kivinen@ssh.fi> writes:
> danmcd@east.sun.com (Dan McDonald) writes:
> > Sorry if this has been repeated before...
> 
> Yes, this was repeated when the IKEv1 was specified, and at that point
> we decided to remove all padding. The reason was that most of the
> material in the packets was still binary byte objects (certificates,
> nonces, key exchange payloads, identities etc) or 8 bit or 16 bit
> numbers. Also the parsing of the IKE payload compared to the
> diffie-hellman / public key signing / verification etc is so fast that
> it really doesn't matter. Disadvantage of padding is that it required
> quite a lot of more code and caused all kind of bugs where
> implementators did that incorrectly.
I tend to agree with Tero here. I'd be extremely surprised if alignment
made any significant performance difference in the IKE/JFK context.

I don't have any specific data for IKE but I do for SSL.  SSL uses a
completely unaligned and rather complicated encoding scheme.  I've
done extensive profiling of SSL/TLS implementations and marshalling
and unmarshalling doesn't consume any significant fraction of the CPU
time required by the implementation.

-Ekr

-- 
[Eric Rescorla                                   ekr@rtfm.com]
                http://www.rtfm.com/