ISAKMP - New Version

["W. Douglas Maughan" <[e-mail]>]

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Content-Lines: 18

All,

A new version of the ISAKMP Internet Draft has been sent to press. It
should be available in the near future. In the meantime, the attached
document explains the changes made from version 6. Most of these
changes were made based on comments received during WG Last Call.

Special thanks to:

	Greg Carter		Nortel
	Richard Waterhouse	GTE
	Dennis Glatting		plaintalk.bellevue.wa.us
	John Burke		Cylink

for their detailed review of version 6 of the protocol specification
and the comments they provided.

Doug Maughan
----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: isakmp_v6_comms
X-Sun-Content-Lines: 323

ISAKMP - Summary and rationale of changes based on comments received
during IPSEC Working Group Last Call

There were several additional minor editorial changes made that are not
included in this summary.

*****************************************************************************

> From [e-mail] Mon Dec 16 15:13:37 1996
> From: "Greg Carter" <[e-mail]>

> I heard CRL\ARL types made it into the draft.  Great!

ACTION:	Accepted 
RATIONALE: Based on agreement at December IETF
LOCATION: Section 3.9

*****************************************************************************

> From [e-mail] Tue Dec 10 08:42:16 1996
> From: "Waterhouse, Richard" <[e-mail]>

> I'm confused, in Section 3.5 length of the SPI is always 8 in a Proposal
> Payload.  Everywhere else the length of the SPI appears to be variable
> length and a function of the Protocol-Id. Why is it handled differently
> in the Proposal Payload ?

ACTION:	Changed Proposal Payload to include a SPI Size field of 1 octet and
	downsized the # of Transforms field from 2 octets to 1 octet.
RATIONALE: To be similar (conceptually) to the Delete and Notify Payloads
	and provide the ability to support multiple protocols with no 
	restriction on SPI length.
LOCATION: Section 3.5

*****************************************************************************

>From [e-mail] Wed Dec 11 08:31:57 1996
> From: "Waterhouse, Richard" <[e-mail]>

> Two questions/comments on version

> 1. The distinction of Major Version and Minor Version is not clear from
> the document. Why isn't there just a Version ? (In particular how should
> the future processing of minor version differ from the future processing
> of major version when there are multiple versions? I usually like to
> provide for future probable evolution paths and the fact that you have
> made this distinction seems to imply you have something in mind that
> isn't explicitly stated.)

> 2. If versioning is useful in ISAKMP itself it would appear to be at
> least as useful at the DOI level (which I would guess would be subject
> to more frequent change than is ISAKMP itself).  Certainly our
> application envisions an evolving DOI with provision for some level of
> backward compatibility.

Response from:

>> From: David Carrel <[e-mail]>

>> 1. The distinction of Major Version and Minor Version is not clear from the 
>> document. Why isn't there just a Version ? (In particular how should the 
>> future processing of minor version differ from the future processing of 
>> major version when there are multiple versions? I usually like to provide 
>> for future probable evolution paths and the fact that you have made this 
>> distinction seems to imply you have something in mind that isn't explicitly 
>> stated.)

> There is no pre-planned use for the minor version numbers.  They can be
> useful, they can also go unused.  Future use of them will be determined
> when we come up with an incompatible change to make.

> Nonetheless, your point is valid that their use is ambiguous.  We should
> define for now that an implementation should never accept packets with a
> major OR minor number that is larger than it's own.  As for accepting ones
> that are smaller, that will be defined as those changes are made.

> One motivation for the distinction between major and minor version is that
> the old 4 bit version number just happens to occupy the same four bits as
> the current major version number.  So if previous implementations of ISAKMP
> receive the current packets, they can easily tell they are the wrong
> version.  Same thing when going the other way as well.

>> 2. If versioning is useful in ISAKMP itself it would appear to be at least 
>> as useful at the DOI level (which I would guess would be subject to more 
>> frequent change than is ISAKMP itself).  Certainly our application 
>> envisions an evolving DOI with provision for some level of backward 
>> compatibility.

> Good thought.  I'll have to ponder this a bit more...

ACTION:	Accepted - Additional text added
	Response to #2 left for editor of the DOI document
RATIONALE: Clarify use of Major and Minor version fields
LOCATION: Section 3.1

*****************************************************************************

> From: [e-mail] (Shawn Mamros)
> Date: Tue, 17 Dec 1996 14:41:59 -0500

> In the isakmp-06 draft, the Notify and Delete payloads both contain
> a Protocol-Id field, so that the SPI(s) contained in those payloads
> can be associated with the proper protocol SA(s) in question.

> However, Protocol-Id values (other than value 1, which is always used
> for the ISAKMP protocol itself) are defined in the DOI document, and
> there is no field in the Notify and Delete payloads which specify which
> DOI is being used.  (The only place the DOI is specified is in the
> Security Association payload.)

> I suppose that, as long as any new Protocol-Id values for any yet-to-
> be-defined DOIs do not conflict with those already assigned for
> IPSEC AH and IPSEC ESP, then this isn't a problem.  But, if there is
> a possibility of conflict, then there will have to be some way to
> associate the Protocol-Id with the proper DOI.  Adding a DOI field
> to the Notify and Delete payloads might be one way to do this, if it's
> needed.

> So, I guess what I'm wondering is: Is there a possibility of conflicting
> Protocol-Ids between different DOIs?  And, if so, what should be done
> about it for the Notify and Delete payloads?  If, on the other hand,
> there will be no conflicts - if all future Protocol-Ids will be unique,
> regardless of DOI - then this should be stated somewhere.

ACTION:	Accepted - DOI field added to the Notify and Delete Payload
RATIONALE: It is feasible that a user could be communicating in more than
	one DOI simultaneously. Therefore, deletions and notifications
	need to be differentiated based not only on the Protocol-ID, 
	but on the combination of DOI and Protocol-ID. 
LOCATION: Sections 3.14 and 3.15

*****************************************************************************

> From: Dennis Glatting <[e-mail]>
> Date: Tue, 24 Dec 96 16:12:44 -0800

>> >From Appendix A of draft-ietf-ipsec-isakmp-06.txt:
>>
>> > Security protocol values 2-1024 are reserved for IANA use.  Values 1025-
>> > 15360 are reserved for future use.  Values 15360-16384 are reserved for
>> > private use.
>> >
>>
>> The future and private use protocol values overlap. Should
>> private use be 15361-16384?
>>

> Also, if protocol values start at 0, the last possible value is
> 16383, not 16384.

ACTION:	Accepted - Values changed accordingly
RATIONALE: Correctness
LOCATION: Appendix A

*****************************************************************************`

> From: Dennis Glatting <[e-mail]>
> Date: Wed, 25 Dec 96 20:40:18 -0800

> I believe draft-ietf-ipsec-isakmp-06.txt does not specify
> byte ordering of integral quantities. Is the ordering network
> order?

ACTION:	Accepted - Text added
RATIONALE: Clarification
LOCATION: Section 3

*****************************************************************************`

> From: "Waterhouse, Richard" <[e-mail]>
> Date: Fri, 3 Jan 1997 09:54:37 -0500

> I need to confirm my understanding of your intent.

> If the examples in Section 4.1.1 occurred within an Aggressive Exchange,
> it would be the NP field of the last Proposal Payload, not the NP field
> of the last Transform Payload, which would identify the following KE
> Payload Type.

> Is this correct ?

Additionally ....

> From: Greg Carter <[e-mail]>
> Date: Wed, 15 Jan 1997 18:46:22 -0500

>    Could those in the know please clarify the next payload for SA
> payloads.  In the examples it is always set to PROPOSAL, but from the
> wording of  the ISAKMP doc it suggests otherwise and my opinion is that
> it should be otherwise, the next NON SA related payload ( ie in
> aggresive mode it would be KE, NONE for Main Mode). 

> Section 4.1 SA Establishment (Page 41 first paragraph)
> ..."An SA establishment message consists of a single SA payload followed
> by AT LEAST one and possible many proposal and transform payloads."

> so there isn't a need to look to the next payload of the SA header to
> know that the data in the SA payload is in fact a proposal.  Since this
> is in the ISAKMP doc I would assume that this would have to hold up
> across any DOI.

> Section 4.1 SA Establishment (Page 42 first paragraph)
> ..."Note that the Next Payload field of the proposal payload points to
> another Proposal (if it exists)."

> same section last paragraph
> ..."Note that the Next Payload field of the Transform payload points to
> another Transform payload or 0."

> So if we can't get it from the proposal or transform(which I don't think
> would be a good idea anyways) then we have to get it from the SA header.

Response from: 

From: [e-mail] (W. Douglas Maughan)
Date: Thu, 16 Jan 97 08:29:52 EST
 
>>    Could those in the know please clarify the next payload for SA
>> payloads.  In the examples it is always set to PROPOSAL, but from the
>> wording of  the ISAKMP doc it suggests otherwise and my opinion is that
>> it should be otherwise, the next NON SA related payload ( ie in
>> aggresive mode it would be KE, NONE for Main Mode). 

> The Next Payload field of an SA payload will point to the next payload
> of the message (if one exists) and not to the Proposal payload as
> version 6 of the draft specifies.

>> Section 4.1 SA Establishment (Page 41 first paragraph)
>> ..."An SA establishment message consists of a single SA payload followed
>> by AT LEAST one and possible many proposal and transform payloads."
>> 
>> so there isn't a need to look to the next payload of the SA header to
>> know that the data in the SA payload is in fact a proposal.  Since this
>> is in the ISAKMP doc I would assume that this would have to hold up
>> across any DOI.

> Correct.

>> Section 4.1 SA Establishment (Page 42 first paragraph)
>> ..."Note that the Next Payload field of the proposal payload points to
>> another Proposal (if it exists)."
>> 
>> same section last paragraph
>> ..."Note that the Next Payload field of the Transform payload points to
>> another Transform payload or 0."
>> 
>> So if we can't get it from the proposal or transform(which I don't think
>> would be a good idea anyways) then we have to get it from the SA header.

> Correct.

ACTION:	Accepted - Text changed and clarifications added
RATIONALE: Next Payload fields of SA, Proposal, and Transform fields 
	modified to simplify processing.
LOCATION: Sections 3.4, 3.5, 3.6, 4.1.1

*****************************************************************************`

> From: John Burke <[e-mail]>
> Date: Thu, 09 Jan 1997 10:41:34 -0500

> TLV Attributes:
> 	The discussion of TLV Attribute format specifies "word alignment";
>	"word" is not a precise term. Two-octet?  Four?  And the wording
>	of this section does not actually say alignment is required, but
>       it sounds like it wants to.
>
>	It unequivocally says any padding must be by leading zeroes; this
>	gives no guidance to someone who invents a character attribute.

ACTION:	Accepted - Text changed and clarifications added
RATIONALE: Clarify use of the Data Attributes
LOCATION: Section 3.3

*****************************************************************************`

> From: John Burke <[e-mail]>
> Date: Thu, 09 Jan 1997 10:41:34 -0500

>      o General:
>	It appears clear to me that all payloads in messages may appear
>	unaligned, since some can have a size of odd bytes.  The text
>	should state this, since the pictures show several things as
>	being four bytes wide though this is not required by the text.
>
>       If we do want alignment it has to be stated explictly, and as
>       "aligned at 4-byte multiples" or "2-byte".

ACTION:	Accepted - Text added
RATIONALE: Clarification
LOCATION: Section 3

*****************************************************************************`

ACTION: Added an additional Certificate Encoding type to diferentiate
	between the use of X.509 certificates for signatures and key 
	exchange.
RATIONALE: X.509 Certificates can be used for both signatures and key
	exchange purposes.  
LOCATION: Section 3.9

*****************************************************************************`

ACTION: Added text to the description of the Payload Length field for
	the Proposal Payload.
RATIONALE: In the event there are multiple proposals with the same
	proposal number, the length field only applies to the specific 
	proposal payload and not to multiple proposal payloads.
LOCATION: Section 3.5

*****************************************************************************`

ACTION: Added text to clarify the processing of the Proposal and
	Transform payloads.
RATIONALE: The initiator may propose multiple proposals, each with
	multiple transforms. THe responder chooses one of these
	proposal and responds to the initiator. The format of this
	returned information can help the protocol processing of the
	initiator.
LOCATION: Section 4.1

*****************************************************************************`