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/
- JFK nit Dan McDonald
- Re: JFK nit Paul Hoffman / VPNC
- Re: JFK nit Dan McDonald
- Re: JFK nit Steven M. Bellovin
- Re: JFK nit Dan McDonald
- Re: JFK nit Tero Kivinen
- Re: JFK nit Eric Rescorla