[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Ordering of payloads
Hi Ben,
To be fair, our ISAKMP implementation also includes a full LDAP client,
full crypto kernel inc PKCS#11, healthy ASN lib, Cert lib, PKIX client
etc. etc..
The point being its not just ISAKMP, in fact my ISAKMP has little impact
on the overall size of the lib. It hasn't been tuned for low
mem/virtual memoryless systems.
My liberal coding practices aside...
Also the payload order code isn't useless, if you want to handle
optional payloads which can arrive anywhere then like it or not you are
going to have to remember payload positions, otherwise your logic for
processing hdr->nextpayload is going to be fun. I tried to do it the
simple way and hope to god everybody else sent me payloads in a
reasonable order. But the code got wacky trying to handle optional
payloads. Maybe you will have better luck.
Again I have no problem with saying SA must be first. I was trying to
point out the consequences if your code can not handle payloads arriving
in order other than those shown in ISAKMP/Oakley and the effect optional
payloads will have on those diagrams.
Bye.
----
Greg "Code Bloat" Carter, Entrust Technologies
greg.carter@entrust.com
Get FREE FIPS-140-1 Validated Crypto for the desktop
http://www.entrust.com/solo.htm
>----------
>From: Ben Rogers[SMTP:ben@Ascend.COM]
>Sent: Friday, September 12, 1997 3:46 PM
>To: John Burke
>Cc: ipsec@tis.com
>Subject: RE: Ordering of payloads
>
>John Burke writes:
>
>> The point here is, do we agree at this time that we should require everyone
>> to do the handling I describe? I.E. find the SA first and do it before
>> passing over the other loads? We actually did not implement this way (nor
>> as I remember did the reference implementation for ISAKMP v-06). But where
>> do others stand, A. for the upcoming interoperation tests and B. later for
>> the final ISAKMP draft?
>
>'twould be nice to have all the code space in the world to work in...
>
>Some of us are extremely restricted as to how much code space we are
>allowed to use. (If I remember the numbers right, on some of our boxes,
>the entire router load needs to fit into less space than Entrust's
>ISAKMP implementation takes.) So, anything that helps us to reduce the
>amount of completely unnecessary processing would be really helpful.
>
>I'm trying to get my brain around the reason it is helpful to allow
>payloads to be in any order, but I am fairly certain we don't lose any
>functionality by requiring that the SA payload in phase I exchanges be
>before any other payloads whose interpretation depend on our SA
>negotiation.
>
>I'm wondering if the WG hasn't been overcome by a bad case of creeping
>featuritis... :)
>
>
>ben
>
>
>
>