[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

proposal payload ID #

	draft-ietf-ipsec-isakmp-10 (section 4.2) says that payload ID #
	of proposal payload and transform payload has to be "monotonically
	increasing number", as attached.
	I noticed that some of existing implementaton barks if we send
	non-contiguous proposal payload ID #, say 1,3,5.  (they are
	happy with 1,2,3, or 10,11,12)
	I would like to know if non-contiguous ID # is allowed or not.

	I feel that, if we are to disallow non-contiguous number,
	the ID # has almost no meaning at all...  Also, "monotonically"
	does not mean "contiguous".

itojun@kame.net
jun-ichiro itoh



(proposal payload)
>The Proposal payload provides the initiating entity with the capability
>to present to the responding entity the security protocols and associated
>security mechanisms for use with the security association being negoti-
>ated.  If the SA establishment negotiation is for a combined protection
>suite consisting of multiple protocols, then there MUST be multiple Pro-
>posal payloads each with the same Proposal number.  These proposals MUST
>be considered as a unit and MUST NOT be separated by a proposal with a
>different proposal number.  The use of the same Proposal number in mul-
>tiple Proposal payloads provides a logical AND operation, i.e.  Protocol
>1 AND Protocol 2.  The first example below shows an ESP AND AH protection
>suite.  If the SA establishment negotiation is for different protection
>suites, then there MUST be multiple Proposal payloads each with a monoton-
								  ~~~~~~~~
>ically increasing Proposal number.  The different proposals MUST be pre-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>sented in the initiator's preference order.  The use of different Proposal
>numbers in multiple Proposal payloads provides a logical OR operation,
>i.e.  Proposal 1 OR Proposal 2, where each proposal may have more than one
>protocol.  The second example below shows either an AH AND ESP protection
>suite OR just an ESP protection suite.  Note that the Next Payload field
>of the Proposal payload points to another Proposal payload (if it exists).
>The existence of a Proposal payload implies the existence of one or more
>Transform payloads.

(transform payload)
>The Transform payload provides the initiating entity with the capability
>to present to the responding entity multiple mechanisms, or transforms,
>for a given protocol.  The Proposal payload identifies a Protocol for
>which services and mechanisms are being negotiated.  The Transform pay-
>load allows the initiating entity to present several possible supported
>transforms for that proposed protocol.  There may be several transforms
>associated with a specific Proposal payload each identified in a separate
>Transform payload.  The multiple transforms MUST be presented with mono-
								   ~~~~~~
>tonically increasing numbers in the initiator's preference order.  The
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>receiving entity MUST select a single transform for each protocol in a
>proposal or reject the entire proposal.  The use of the Transform num-
>ber in multiple Transform payloads provides a second level OR operation,
>i.e.  Transform 1 OR Transform 2 OR Transform 3.  Example 1 below shows
>two possible transforms for ESP and a single transform for AH. Example 2
>below shows one transform for AH AND one transform for ESP OR two trans-
>forms for ESP alone.  Note that the Next Payload field of the Transform
>payload points to another Transform payload or 0.  The Proposal payload
>delineates the different proposals.