[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    Re: JFK nit
From:       Eric Rescorla <ekr () rtfm ! com>
Date:       2002-05-15 16:09:06
[Download RAW message or body]

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/
[prev in list] [next in list] [prev in thread] [next in thread]