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

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

Hi Tero,

I am adding the set of comments not yet addressed or not yet resolved. I have updated the comments (based on feedback from you) and have also added definitive text wherever possible: -

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

Integrity Algorithm (INTEG)     3  (IKE, AH, optional in ESP)

I think we can remove the "optional" in ESP part for Integrity Algorithm. The ESP document states that: -
            "
            - confidentiality-only (MAY be supported)
            - integrity-only (MUST be supported)
            - confidentiality and integrity (MUST be supported)"

Besides NONE should not be used as the integrity algorithm in Section 3.3.2? It would also make things clearer if it was stated that when confidentiality service is not used we should use 

3. Section 3.3.3 change

          Protocol  Mandatory Types        Optional Types
            IKE     ENCR, PRF, INTEG, D-H
            ESP     ENCR                   INTEG, D-H, ESN
            AH      INTEG                  D-H, ESN
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."

to be changed to

"For all messages that follow, the message following 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, if we are putting in values we should specify the range properly. Otherwise it is good enough to remove the part from the document itself.

6. In Section 2.13 we talk about (K, S) but never specify what K or S mean. Tero, mentioned they are inputs. I am not sure if we can replace K and S with Y, Z. If yes, we can leave it as it is else we need to specify what they mean.

7. IKE document talks about ECN, but won't 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.

The text for DSCP is 

"2.23 DSCP (DiffServ Code Point)

   When IPsec tunnels behave as originally specified in [RFC2401], DSCP
   usage is not appropriate for the outer IP headers because tunnel
   decapsulation processing can discard DSCP values.
    
   IKEv2 simplifies this situation by requiring that DSCP values be 
   usable in the outer IP headers of all tunnel-mode IPsec SAs
   created by IKEv2. The decapsulating process needs to copy the DSCP
   value to the outer header as specified in [RFC2401bis]."

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. Though Tero pointed out a quote from the draft, it is clear that it does not specify how to treat received values.

I am ok, posting errata if the text cannot be added in the current version of the document (document being in the RFC-Editor).

Thanks,
Vishwas
________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Vishwas Manral
Sent: Monday, January 31, 2005 10:55 PM
To: Tero Kivinen
Cc: [email-masked]
Subject: RE: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt

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

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 4 Feb 2005 11:24:05 +0200

Vishwas Manral writes:
> Algorithm. The ESP document states that: - 

No we CANNOT remove the optional. 

>             - confidentiality and integrity (MUST be supported)"

If you support the confidentiality-only (which is MAY) you MUST be
able to negotiate it in the IKE, which means that integrity algorithm
in ESP must be something optional, so that you can leave it out. 

> Besides NONE should not be used as the integrity algorithm in
> Section 3.3.2? It would also make things clearer if it was stated
> that when confidentiality service is not used we should use

True the NONE integrity algorithm makes it little bit unclear what you
want to do when negotiating the ESP without integrity, you have two
choices:

1) Do not include integrity algorithm at all (as MUST be done in case
   of combined algoritms as said in section 3.3, but this cannot be
   used if you have other INTEG algorithms in your proposal)

2) Include integrity algorith NONE (in which case you can omit it if
   that is the only algorithm, as said in 3.3.3).

The reason we need NONE there is that if initiator wants to propose
AES + SHA1 or AES without integrity. The ENCR proposal will have AES,
and the INTEG proposal will have AUTH_SHA1 and NONE. 

>             ESP     INTEG, ENCR            D-H, ESN <<== changed here

Once again, we cannot make that change.

> "For all messages that follow, the message following the header is
> encrypted and the message including the header is integrity
> protected."

That change would be ok.

> 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, if we are putting in
> values we should specify the range properly. Otherwise it is good
> enough to remove the part from the document itself.

I do not think we have any problem here, and we cannot remove that
text. I think it is obvious that all negative message ids ar outside
of window.

> S mean. Tero, mentioned they are inputs. I am not sure if we can
> replace K and S with Y, Z. If yes, we can leave it as it is else we
> need to specify what they mean.

Why would we want to replace them with Y or Z? They are just letters,
and any letter is ok there. The reason they are selected as K and S,
is that the K is the input for the key, and S is probably specifying
the string or something.

> 8. We may want to state (obvious) that IKE message on port 4500,
> send the bytes as 0. Though Tero pointed out a quote from the draft,
> it is clear that it does not specify how to treat received values.

The UDP encapsulation rfc says what to do with the other values, as
all other values than zero are processed as SPIs, which means that in
normal case they will never even came to the IKE, as the IPsec
processing in the kernel already processes them. 

> I am ok, posting errata if the text cannot be added in the current
> version of the document (document being in the RFC-Editor).

I do not think there is anything else to fix than the typo, and
perhaps adding the clarification to section 1.2 about the coverage of
the integrity.
-- 
[email-masked]