[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SA, Proposal and Transform payloads
Roy,
> The current ISAKMP draft, draft-ietf-ipsec-isakmp-06.txt [isakmp],
> defines a new method to exchange proposals.
ISAKMP-06 does not define a "new" method. What has been done is the
combining of the ENVelope payload, Collate bit of the Flags field, and
Appendix A material from ISAKMP-05. Additionally, ISAKMP-06 now
supports multiple proposals using different logical AND and OR
constructs.
> 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.
Agreed they are not used at the 'same level' as other payloads and are
only used as part of the SA negotiation. The reason they were included
as payloads and include the generic payload header is for processing
reasons. Using this method all payload headers can be processed using
the same code. In the end, the 'naming' or 'equating' is not really
that important.
> 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.
This may be true for IPSEC and the method of establishing SAs using the
Proposal and Transform payloads, but I'm not sure you can make the same
blanket statement for all possible DOIs.
> 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.
We changed the protocol so that all payloads had the same header. This
was done for efficiency and simplicity. It's easy to say, "Get rid of
the Next Payload" field, but "Add another field in the SA Payload".
Significant thought went into the current method. I'll leave it up to
the IPSEC WG, co-chairs, and others to debate the necessity of the
proposed changes. In the end, I don't think you're saving very much
bandwidth and I'm not convinced the proposal is "more simple". A good
exercise might be to look at the savings when a complex proposal (e.g.
(ESP{DES OR 3DES} AND AH{MD5 OR SHA}) OR (HUGHES)) is made.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* Douglas Maughan Voice: (301) 688-0847 *
* Technical Director, R23 Fax: (301) 688-0255 *
* National Security Agency E-mail: wdmaugh@tycho.ncsc.mil *
* 9800 Savage Road maughan@cs.umbc.edu *
* Fort Meade, MD. 20755-6000 *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *