RE: Ordering of payloads

John Burke <jburke@cylink.com> Fri, 12 September 1997 18:36 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA09031 for ipsec-outgoing; Fri, 12 Sep 1997 14:36:09 -0400 (EDT)
Message-Id: <3.0.32.19970912114639.00905470@192.43.161.2>
X-Sender: jburke@192.43.161.2
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 12 Sep 1997 11:46:39 -0700
To: ipsec@tis.com
From: John Burke <jburke@cylink.com>
Subject: RE: Ordering of payloads
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

Maybe we want to consider this a little more?

Greg C. was a "real programmer" here and apparently handled payload
ordering and the SA in the most robust way.  Just to state clearly what
this requires:

 1. Sanity check: discover what payloads are present and assure no
    malformations.
    While doing this remember where payloads are, particularly the SA load.

 2. Payload handling:

	A. If an SA Payload was present, go to its location first, decode
	it, select and validate, and set all relevant parameters in your
	SA block.

	B. Once you have done that, suck in all other parameters.  You can
	go through these in any order, saving their values in your SA (BUT
	NOTE that for ID's in Quick Mode their order of arrival must be
	used to separate IDi, IDr).

	C. Finally take the actions required for the message, e.g. key	
	derivations and formation of a response.

Now I wonder how many of the existing implementations support order-free
handling of the SA load as I describe above?  Sure if the early ISAKMP
specs had said explicitly that payloads can appear in any order maybe
everyone would have been scared into doing it; but did they?

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?

I see nothing wrong with the SA load being singled out as having to be (not
"first" but) ordered per the diagrams, while other loads can be in any
order; I feel the procedure described above is enough to point out why it
is different.  Certain Hash loads are already singled out in this manner.
The only kind of argument I could see is, if someone has implementation
reasons why it would help to be able to put SA in a different position.

This is not to make a big deal of this, just to ask people to think before
acting, and to mention what we would like.  We'll do whatever people agree on.

- John Burke

At 08:07 AM 9/12/97 -0400, Greg Carter <greg.carter@entrust.com> wrote:
>Hi Tero,
[ ... ]
>On the original subject...
>I agree with Tero, given the fact you have to flip through the packet
>for a sanity check anyways, you have an opportunity to figure out where
>everything is.  Added on top of that the fact that the other payloads
>can come in any order (but in a specific group sequence) there is no
>added complexity in finding the SA payload and processing it in the
>order you require.  ISAKMP also states that some optional payloads must
>be accepted at any point in the exchange (not that I would ever stick
>anything before the SA).  
>
>But specifying it must be first doesn't really bother me either :)
>
>Bye
>----
>Greg Carter, Entrust Technologies
>greg.carter@entrust.com
>Get FREE 128-bit FIPS-140-1 Validated Crypto for the desktop
>http://www.entrust.com/solo.htm

Tero Kivinen <kivinen@ssh.fi> wrote:
> I don't think it will make much difference if the SA payload first or
> not. If one argues that it would be easier, then one might just say
> that every packet must be exactly the order given in draft, because
> that would make things even more easy...