Re: KINK issue list rev.2

> #1 [**] Versioning
> 
> 	what happens when a receiver receives a major or
> 	minor version of the kink or qm that is inconsistent with this
> 	document?  What about unknown payload types?  (Sam Hartman)
> 
> 	QM version is discussed in section 12 (Forward Compatibility
> 	Considerations).
> 
> 	- KINK version
> 		return error (KINK_INVMAJ, KINK_INVMIN)

it would be better for me that the document described:

	- an implementation should return a KINK error
	  with KINK_INVMAJ (or KINK_INVMIN), when an implementation
	  receives an unsupported kink version number in the header.
	- in the security consideration section, an implementation
	  MUST consider to trust unauthorised messages.

> 	- QM versoin
> 		already specified in section 12.

it is clearly described in the section 12.

> 	- KINK payload type
> 		return error (KINK_PROTOERR)

it is enough for me that an implementation return a kink error message
with this error type.  however it would be better that the document
had the description of behavior when an implementation received
unsupported payload.

> 	- ISAKMP payload type
> 		return error (ISAKMP INVALID-PAYLOAD-TYPE)
> 		(describe each Notify type usage like ikev2 spec.)

it is described in RFC2408 when an implementation receives a message
contained unsupported ISAKMP payload type.  so it may be unneccesary
to describe here explicitly.  however there are few description in
the IKEv1 specification when other errors happen.  that will bring
an interoperability problem for KINK.  so i think the document should
have detail descriptions like the IKEv2 specification.

> 	Specify the behavior when the error is not authenticated
> 	in the Security Consideration section.

for example, in the draft-ietf-ipsec-ikev2-17.txt:

2.21 Error Handling

   Errors that occur before a cryptographically protected IKE_SA is
   established must be handled very carefully. There is a trade-off
   between wanting to be helpful in diagnosing a problem and responding
   to it and wanting to avoid being a dupe in a denial of service attack
   based on forged messages.

i am not sure why the description is not in the security consideration.