Re: KINK issue list rev.2

At Wed, 02 Feb 2005 12:43:48 -0800,
Michael Thomas <[email protected]> wrote:
> 
> On Wed, 2005-02-02 at 12:32, Sam Hartman wrote:
> > >>>>> "Michael" == Michael Thomas <[email protected]> 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.
> 
> Well, I'm actually asking what others want here. I sort
> 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 protected]>