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

From: Dan Harkins <[email-masked]>
Date: Tue, 03 Apr 2001 13:18:07 -0700

Hi,

  I have a couple comments on the kink draft. 

  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.

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

  Dan.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 3 Apr 2001 14:31:31 -0700 (PDT)

> of ISAKMP or TLS for example? And OSPF doesn't define a SPI.

   I'm not quite groking this, but I can say that a
   rewrite of this section is underway by Tero to
   directly lift the pertinent parts of IKE to as
   you say fully specify the IKE payloads we're using
   within the KINK draft. I sense that that is not
   what your issue is... Maybe Tero or somebody else
   can help here.

 > 32 bit aligned header seems excessive (figure 13). 

   I agree. I've been meaning to make a pass on all
   of these to clean up these kinds of bogisities and
   especially watch out for gratuitious bit alignment
   problems so as to streamline the processing.

	    Mike