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

From: "Vishwas Manral" <[email-masked]>
Date: Sun, 30 Jan 2005 04:16:58 -0800

Hi,

I noticed the document in the RFC editor queue, if so I can send the comments as an RFC errata itself later. Here are some small  "nits" I came across: -

1. Section 2.13 -  states "**they** algorithm by which keys are derived from arbitrary values MUST be specified by the cryptographic transform. " Typo.

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.

3. Section 3.3.3

          Protocol  Mandatory Types        Optional Types
            IKE     ENCR, PRF, INTEG, D-H
            ESP     ENCR                   INTEG, D-H, ESN
            AH      INTEG                  D-H, ESN

To be changed to

          Protocol  Mandatory Types        Optional Types
            IKE     ENCR, PRF, INTEG, D-H
            ESP     INTEG                  ENCR, D-H, ESN <<== changed here
            AH      INTEG                  D-H, ESN

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

5. "In other words, if the responder stated its window size is N, then when the initiator needs to make a request X, it MUST wait until it has received responses to all requests up through request X-N." This statement may not be true for X < N.

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

7. IKE document talks about ECN, but wont a similar case be there for DSCP values. I think DSCP values should be copied from the Outer header back to the inner header too. 

Also the above could be specified in the draft-ietf-ipsec-rfc2401bis-05.txt draft too.

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.

Thanks,
Vishwas

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

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 31 Jan 2005 16:27:01 +0200

Vishwas Manral writes:
> 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.

> 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

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]