Subject: comments on draft-ietf-kink-kink-00.txt

From: Michael Thomas <[email-masked]>
Date: Thu, 17 May 2001 14:44:04 -0700 (PDT)

[old, but I'm trying to clear out the comments...]

Dan Harkins writes:
 >   The verbage from RFC2408 which seems to mandate a covert channel has 
 > been copied into this draft. In section 7.4 where it talks about the SPI 
 > size it says:
 > 
 >      "In the case of ISAKMP, the Initiator and Responder cookie pair 
 >       from the ISAKMP Header is the ISAKMP SPI, therefore, the
 >       SPI Size is irrelevant and MAY be from zero (0) to sixteen (16). 
 >       If the SPI Size is non-zero, the content of the SPI field MUST 
 >       be ignored."
 > 
 > This text should be removed. The SPI size should depend on the protocol
 > and either it MUST be a fixed something or it MUST be nothing. The 
 > protocol-id should be better defined as well. What is the protocol id 
 > of ISAKMP or TLS for example? And OSPF doesn't define a SPI.

Dan, 

The decision at last ietf was to use IKE Phase II
directly for SA establishment. The current plan is
to directly reference 2409, but place a
major/minor version into the ISAKMP payload
header so that we are future proofed for any
son-of-IKE revisions. Thus, I think your concern
is addressed.

 >   I also think it would be better to have kink define itself fully and 
 > not depend on another document for payload and/or magic number definitions. 
 > Since each payload from RFC2408 that is used in kink is redefined here that 
 > shouldn't really be an issue. This would allow the "InnerNextPayload" 
 > followed by 24 bits of zeros to go away. Having 32 bits of RESERVED in a 
 > 32 bit aligned header seems excessive (figure 13). 

It's down 24 now :-| The same problem exists with
the KINK_ENCRYPT payload. Sigh. One thing this
does protect is what the type of the first
inner payload is though, so maybe this is
right for encrypt.

	Mike