Subject: Re: KINK issue list rev.2

From: Shoichi Sakane <[email-masked]>
Date: Wed, 02 Feb 2005 10:54:20 +0900

> #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.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Feb 2005 21:25:30 -0500

Speaking as an individual, normally when there is a major version and
a minor version the intent is that using a greater minor version than
one side expects is acceptable.

--Sam

---

From: Shoichi Sakane <[email-masked]>
Date: Wed, 02 Feb 2005 11:49:30 +0900

> one side expects is acceptable.

correct.  do you comment that the document does not touch a minor version ?

---

From: Sam Hartman <[email-masked]>
Date: Wed, 02 Feb 2005 14:06:49 -0500

>>>>> "Shoichi" == Shoichi Sakane <[email-masked]> writes:

    >> Speaking as an individual, normally when there is a major
    >> version and a minor version the intent is that using a greater
    >> minor version than one side expects is acceptable.

    Shoichi> correct.  do you comment that the document does not touch
    Shoichi> a minor version ?

Correct.  The only thing I find is an invalid minor version error and
a requirement that implementations MUST use version 1.0.  It doesn't
say what happens if a recipient receives a greater minor version.

Again, if the WG wants to use minor versions the same as major
versions, that's OK but needs to be called out because it is not what
people expect.

--Sam

---

From: Michael Thomas <[email-masked]>
Date: Wed, 02 Feb 2005 12:19:30 -0800

> versions, that's OK but needs to be called out because it is not what

From a jaded perspective: when is the last time a minor
version on a protocol has actually helped? Or for that
matter a major version?

Usually the semantics of major/minor or non-backward
compatible vs. backward compatible. That is, a receiver
MUST be able to deal with a higher minor version and
just ignore things it doesn't understand. But as I say,
in practice things get a lot messier. Maybe this would
be a way to deal with new IKEv2 stuff, but it's all
rather dependent on what morphed with phase 2 payloads.

So I'm rather ambivalent. The current phrasing will certainly
do it's main job: stopping a receiver from incorrectly parsing
future versions and the potential exploits that could result.
Maybe we really should leave it at that if for no other
reason from a security/system analysis standpoint.

		Mike

---

From: Sam Hartman <[email-masked]>
Date: Wed, 02 Feb 2005 15:32:22 -0500

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:

    Michael> So I'm rather ambivalent. The current phrasing will
    Michael> certainly do it's main job: stopping a receiver from
    Michael> incorrectly parsing future versions and the potential
    Michael> exploits that could result.  Maybe we really should leave
    Michael> it at that if for no other reason from a security/system
    Michael> analysis standpoint.

If you want to leave it please at least say that the receiver must
send back the appropriate bad version error.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 02 Feb 2005 12:43:48 -0800

> send back the appropriate bad version error.

Well, I'm actually asking what others want here. I sort
of tend toward this, but it's not just my call here...

		Mike

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Thu, 03 Feb 2005 13:09:59 +0900

At Wed, 02 Feb 2005 12:43:48 -0800,
> of tend toward this, but it's not just my call here...

I have no problem on returning KINK_INVMIN.
If we would accept unknown minor version, we were likely to come up
against unknown payload type, and result to return an error.
If we want to address this, we might need a flag like the "critical"
bit of IKEv2, but I think KINK doesn't need such complexity.

# If the initator would like to establish SAs at any cost,
# it can fallback to KINK version X.0 anyway.

-- 
KAMADA Ken'ichi <[email-masked]>

---

From: Shoichi Sakane <[email-masked]>
Date: Fri, 04 Feb 2005 19:22:17 +0900

> of tend toward this, but it's not just my call here...

I don't think KINK will have minor change often, and I don't think the
minor version will bring worth things to KINK.  so I feel that I want
to remove the minor version from KINK specification.

However, if we will leave it, it is policy matter to process a message
with a higher minor version.  so we have to describe like below:
	if a endpoint receives a message with a higher major version
	number, it MUST drop the message and SHOULD send a KINK_ERROR
	with KINK_INVMIN.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Feb 2005 06:51:22 -0800

> to remove the minor version from KINK specification.

I fine with this is others are fine with this too.

		Mike