Re: KINK and RFC2401bis

Hello,

I'm Kazunori Miyazawa. I'm implementing KINK into a small embedded device.

I agree with Mr. Tomas. KINK does not specifiy its payload about IPsec SA
and relegates it to ISAKMP so that the conformity to rfc2401bis depends
on how ISAKMP conforms rfc2401bis.

I think changing the reference from IKEv1 to IKEv2 needs to many
revises on the draft because IKEv2 does not have the phases. If the draft
referencig IKEv2, I guess KINK uses CREATE_CHILD_SA exchange instead of ISAKMP
quick mode. If we only reuse each IKEv2 payload format, we need more definition
in section 7.


Michael Thomas wrote:
> I'm fairly certain that the main difference required of
> KINK is to change the normative reference from IKEv1 to
> IKEv2 for ISAKMP payloads. KINK doesn't do anything with
> the payloads themselves, though there may be some error
> code differences if my foggy memory on this subject 
> serves me. When I coded this up with the Pluto sources
> for IKEv1, I didn't have to change any of the internal
> SA establishment/destruction code at all.
> 
> 
> 		Mike
> 
> On Tue, 2005-01-04 at 12:11, Sam Hartman wrote:
> 
>>I finished reading over RFC 2401bis this morning.  By the time Kink
>>makes its way to the IESG, it will need to normatively reference that
>>document instead of RFC 2401.
>>
>>The primary change is that several of the comments about the SPD
>>actually apply to the PAD in the 2041bis model.
>>
>>
>>
>>There's another issue the working group needs to consider.  RFC
>>2401bis increases the flexibility and requirements for IPsec.  New
>>requirements include the ability to have multiple SAs with the same
>>selectors and to have port ranges in selectors.  IKEv1 which Kink is
>>based on does not support these features.
>>
>>I'm concerned that people will expect to be able to set up SPD entries
>>taking advantage of such features and have them work.  I'm asking the
>>working group to seriously consider whether support for new IPsec
>>requirements should be added to Kink.  The result of this
>>consideration needs to be either modifications to the protocol to add
>>the necessary support or text explaining what features are not
>>supported and why the working group has chosen not to support them.
>>
>>--Sam

--
Kazunori Miyazawa