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

From: Jonathan Trostle <[email-masked]>
Date: Thu, 05 Apr 2001 23:09:42 -0700

>Dan Harkins writes:
> >   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'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.

Dan is asking that you specify the SPI size more tightly.  If it's not
needed, perhaps it should be 0. Don't give an implementation any
unnecessary flexibility here. 

Jonathan

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