Subject: RE: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 31 Jan 2005 09:24:51 -0800

Hi Tero,
 
Thanks a lot for the reply. My comments are prefixed with a "VM>"
 
> "All but the headers of all the messages that follow are encrypted and integrity protected."
>
> Do we also mean to say that the header is integrity protected but
> not encrypted? We may want to clarify the text, and instead state
> "For all messages that folllow, the header is encrypted and the
> message including the header is integrity protected."

Header is not encrypted, the data after header is encrypted, so your
text is actually incorrect. It is true we could clarify that the
header is also integrity protected....
VM> I guess I agree the text I gave confused it further. What I meant is everything after the header is encrypted, and including the header is integrity protected.  Maybe the text you state is clearer.
 
> 2. Section 3.3.2 - Transform type Values: -
>
> Encryption Algorithm (ENCR)     1  (IKE and ESP)
> Integrity Algorithm (INTEG)     3  (IKE, AH, optional in ESP)
>
> I think we can remove the "optional" in ESP part for Integrity
> Algorithm. The optional part could be added instead to the
> Encryption Algorithm part.

No, we cannot remove that. Integrity is optional in ESP. Encryption is
NOT optional in the ESP. If you do not want to use encryption in ESP,
you need to negotiate cipher called ENCR_NULL.
VM> I think we can remove the "INTEG part is optional" in ESP part of it. If I see the Architecture document right, that is what is stated very clearly. Am I missing something there? This discrepancy seems to be in a lot of drafts. 

> 6.  In Section 2.13 we talk about (K, S) but never specify what K or
>     S mean.
I think it is quite obvious that they are inputs to the function
prf+...
VM> Being a first time reader, I couldn't figure out what K and S stand for(inputs to the function for sure, what do they mean). It was not defined before or even in the same section(though everything else was).
 
> 8.  We may want to state(obvious) that IKE message on port 4500,
>     MUST have the first 4 bytes as zero on receipt and should always
>     send the bytes as 0.
I think the section 3.1 says that:
----------------------------------------------------------------------
   When sent on UDP port 4500, IKE messages have prepended four octets
   of zero. These four octets of zero are not part of the IKE message
   and are not included in any of the length fields or checksums
   defined by IKE.
VM> I do not agree, it anywhere states that a value of non-zero on input is a wrong  value. I think as a good protocol specification, we should clearly specify the behavior even in cases where an incorrect value is received(spcefying the values to receive). I know things may seem obvious to you but I guess to anyone implementing this, it may not. Though I have not worked on IKE for long enough, I have figured this out working and documenting other protocols.
 
Thanks,
Vishwas
________________________________

From: Tero Kivinen [mailto:[email-masked]]
Sent: Mon 1/31/2005 6:27 AM
To: Vishwas Manral
Cc: [email-masked]
Subject: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt

Vishwas Manral writes:
> 2. Section 3.3.2 - Transform type Values: -
>
> Encryption Algorithm (ENCR)     1  (IKE and ESP)
> Integrity Algorithm (INTEG)     3  (IKE, AH, optional in ESP)
>
> I think we can remove the "optional" in ESP part for Integrity
> Algorithm. The optional part could be added instead to the
> Encryption Algorithm part.

No, we cannot remove that. Integrity is optional in ESP. Encryption is
NOT optional in the ESP. If you do not want to use encryption in ESP,
you need to negotiate cipher called ENCR_NULL.

> 4. Section 1.2 states: -
>
> "All but the headers of all the messages that follow are encrypted and integrity protected."
>
> Do we also mean to say that the header is integrity protected but
> not encrypted? We may want to clarify the text, and instead state
> "For all messages that folllow, the header is encrypted and the
> message including the header is integrity protected."

Header is not encrypted, the data after header is encrypted, so your
text is actually incorrect. It is true we could clarify that the
header is also integrity protected....

> 6.  In Section 2.13 we talk about (K, S) but never specify what K or
>     S mean.

I think it is quite obvious that they are inputs to the function
prf+...

> 8.  We may want to state(obvious) that IKE message on port 4500,
>     MUST have the first 4 bytes as zero on receipt and should always
>     send the bytes as 0.

I think the section 3.1 says that:

----------------------------------------------------------------------
   When sent on UDP port 4500, IKE messages have prepended four octets
   of zero. These four octets of zero are not part of the IKE message
   and are not included in any of the length fields or checksums
   defined by IKE.
--
[email-masked]

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec