Re: KINK and RFC2401bis

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iQCVAwUAQdsIdLMsDAj/Eq++AQK1DQP/fQdUzKHsdczDptpenOyddXs/nbaoX+f9
iNgZpeIi99WOwNjaxNxkuZ2eoM7gIl/VZPGHqRR7VrjBo0BmUJCwtoHsQvDbqWld
gSSOp0beXb2PnT8jALYDLFC8LpQJnzqNfxO0bxBJaKQ8vIiParU59FrpQIMd/azU
9BWR9gcyfT8=
=dDMI
-----END PGP SIGNATURE-----