[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SA, Proposal and Transform payloads
>
>The current ISAKMP draft, draft-ietf-ipsec-isakmp-06.txt [isakmp], defines a
>new method to exchange proposals.
>
>It states that the proposals and transforms are payloads and thus have the
>same generic payload structure. Logically, though they are not used at the
>'same level' as all other payloads. They are only used within, or after, the
>SA payload. Furthermore, the Transform payload is only used within a
>Proposal payload. I think it might be confusing and logically incorrect to
>call these two structures 'payloads' and have them equate to the other
>payloads.
>
>Thus, the only valid 'Next Payload' value for the SA payload is 'Proposal'.
>The only valid 'Next Payload' value for a Proposal payload is 'Transform' or
>NIL. And the only valid 'Next Payload' value for the Transform payload is
>'Transform' or NIL. Thus I believe that this field confuses the process of
>parsing a complete proposal.
>
>I propose moving the Proposal and Transform structures away from the
>'Payload' definition and as well as simplifying them.
>
>Proposal :=
> Proposal Number 1 octet
> Protocol ID 1 octet
> Length 2 octets
> Number of Transforms 2 octets
> Reserved 2 octets
> SPI 8 octets
>
>Transform :=
> Transform Number 1 octet
> Transform ID 1 octet
> Length 2 octets
> Attributes... multiple of 4 octets
>
>The main advantage is the removal of the 'Next Payload' field. For this to
>work properly though, we require another field in the SA payload to state how
>many proposals we are sending. Or we can utilize the 'Reserved' field in the
>Proposal structure and add a flag that denotes whether there are any other
>proposals after this one.
>---------------------------------------------
>Roy Pereira TimeStep Corporation
>rpereira@timestep.com Ottawa, Ontario
>613-599-3610 x 4808 http://www.timestep.com
>