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

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 4 Feb 2005 02:47:52 -0800

Hi Tero,

Thanks for the detailed reply. If you think it all ok we can leave it
here. 

However I am still confused about why we talk about ECN and not DSCP.
Also I still believe we should specify behavior more clearly about
receiving messages on 4500(if it is specified in another RFC, do we need
to write anything about the send itself, isn't sending specified in the
UDP encapsulation?). On why K, S are used yet nowhere specified what
they mean (while everything else is explained). On why we give " 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.", when it is self
explanatory anyway, and if we give it why we do not define the ranges of
things we talk about.

Thanks again,
Vishwas
-----Original Message-----
From: Tero Kivinen [mailto:[email-masked]] 
Sent: Friday, February 04, 2005 2:54 PM
To: Vishwas Manral
Cc: [email-masked]
Subject: RE: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt

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

No we CANNOT remove the optional. 

>             "
>             - confidentiality-only (MAY be supported)
>             - integrity-only (MUST be supported)
>             - 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. 

> 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

Once again, we cannot make that change.

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

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.

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

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

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]

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

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 4 Feb 2005 17:28:51 +0200

> However I am still confused about why we talk about ECN and not DSCP.

DSCP values are copied during the encapsulation, and they are not
changed during the decapsulation, thus there is no need to do anything
special there.

The ECN values are similarly copied during the encapsulation, but in
the decapsulation they are reconstructed based on the both inner and
outer ECN values.

The processing of the ECN has changed from the rfc2401 to RFC2401bis,
and the RFC3168 describing ECN had a negotiation method how to
negotiate that the ECN bits are processed like in rfc2401bis. The text
we have about ECN in the IKEv2 draft simply says, that all SAs
negotiated using IKEv2 must construct the ECN bits, i.e the
negotiation of that feature is no longer needed. 

> UDP encapsulation?).

UDP encapsulation is described in the RFC 3948, and we already have
reference to that in few places. I do not think we need to say
anything more about the issue, than simply say that IKE packets are
prepended with 4 bytes of zero. 

> On why K, S are used yet nowhere specified what they mean (while
> everything else is explained).

As I said they are inputs to the function of prf+. I do not think they
need to be explicitly specified as such, as it is obvious from the
context. 

> On why we give " In

That text explains how the windows work in general. If we remove it
then the text will be hard to understand. 
-- 
[email-masked]