Subject: IETFLC comments for draft-ietf-ipsecme-ikev2bis-08

From: <[email-masked]>
Date: Sat, 6 Mar 2010 12:55:37 +0100

I've gone through changes from 06 to 07/08, and my earlier
comments, and found one minor bug and couple of small editorial
suggestions/nits.

The bug first:

- Section 3.3.6 says "If one of the proposals offered is for the
Diffie-Hellman group of NONE, the responder MUST ignore the
initiator's KE payload and omit the KE payload from the response."

This seems wrong: it seems to say that if the initiator proposes DH
group NONE, the responder must select it.

However, negotiation of DH groups and KE payload is already well
described in Sections 1.2 and 1.3 (paragraphs mentioning
INVALID_KE_PAYLOAD), and it seems the last paragraph of 3.3.6 is
completely redundant. Thus, I'd propose just deleting the whole
paragraph.

Editorial suggestions/nits:

- Section 2.7, last paragraph, is in wrong place; rest of 2.7 has
nothing to do with this topic, which is in 2.6. Suggested place: 2.6,
end of paragraph starting with "In the first message".
Also, "the responder's SPI will be zero" should be "the responder's 
SPI will be zero also in the response message" (since the responder's 
SPI is always zero in the IKE_SA_INIT request, but that's not what 
this paragraph is about).
 
- One of the changes is listed in Section 1.7 twice. I'd suggest
combining

   In section 1.3.2, changed "The KEi payload SHOULD be included" to be
   "The KEi payload MUST be included".  This also led to changes in
   section 2.18.

and

   Section 2.18 requires doing a Diffie-Hellman exchange when rekeying
   the IKE_SA.  In theory, RFC 4306 allowed a policy where the Diffie-
   Hellman exchange was optional, but this was not useful (or
   appropriate) when rekeying the IKE_SA.

as follows:

   This document requires doing a Diffie-Hellman exchange when
   rekeying the IKE_SA (and thus requires including the KEi/KEr
   payloads).  In theory, RFC 4306 allowed a policy where the
   Diffie-Hellman exchange was optional (and KEi/KEr payloads could be
   omitted), this was not useful (or appropriate) when rekeying the
   IKE_SA.

- Section 2.8.2, last paragraph: it's not quite obvious why this
should be negotiated (the reason is that this notification was not
included in RFC 4306, but this section never says that). Suggested
rephrasing

   The TEMPORARY_FAILURE notification was not included in RFC 4306,
   and support of the TEMPORARY_FAILURE notification is not negotiated.
   Thus, older peers (implementing RFC 4306) may receive [... rest
   of the paragraph unchanged...]

- Section 2.23, paragraph starting: "An initiator can use...".
IKEv2 packets are always over UDP, so IMHO the text would benefit
from some more precision when talking about UDP encapsulation.
Suggested edits:

OLD:
   An initiator can use port 4500 for both IKE and ESP, regardless of
   whether or not there is a NAT, even at the beginning of IKE.  When
   either side is using port 4500, sending with UDP encapsulation is not
   required, but understanding received IKE and ESP packets with UDP
   encapsulation is required.  UDP encapsulation MUST NOT be done on
   port 500.  If NAT-T is supported (that is, if NAT_DETECTION_*_IP
   payloads were exchanged during IKE_SA_INIT), all devices MUST be able
   to receive and process both UDP encapsulated and non-UDP encapsulated
   packets at any time.  Either side can decide whether or not to use
   UDP encapsulation irrespective of the choice made by the other side.
   However, if a NAT is detected, both devices MUST send UDP
   encapsulated packets.
NEW:
   An initiator can use port 4500 for both IKE and ESP, regardless of
   whether or not there is a NAT, even at the beginning of IKE.  When
   either side is using port 4500, sending ESP with UDP encapsulation
   is not required, but understanding received UDP encapsulated ESP
   packets is required. If NAT-T is supported (that is, if
   NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all
   devices MUST be able to receive and process both UDP encapsulated
   ESP and non-UDP encapsulated ESP packets at any time.  Either side
   can decide whether or not to use UDP encapsulation for ESP
   irrespective of the choice made by the other side.  However, if a
   NAT is detected, both devices MUST use UDP encapsulation for ESP.

- Section 3.5: "ID_IPV6_ADDR instead of ID_IPV6_ADDR" should
be "...instead of ID_IPV4_ADDR"?

- Reference [PKIX] should be updated from RFC 3280 to 5280.

- Section 2.23.1, "hve" -> "have"

Best regards,
Pasi

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 6 Mar 2010 17:27:32 -0800

>this paragraph is about).

Agree.

>   omitted), this was not useful (or appropriate) when rekeying the

Disagree. Where possible, I tried to list the actual sections where changes were made, and your proposed rewording loses the two places. The current text is more explicit than the proposed change.

>   of the paragraph unchanged...]

Agree.

>   NAT is detected, both devices MUST use UDP encapsulation for ESP.

Yes, that's clearer.

>be "...instead of ID_IPV4_ADDR"?

Yep.

>- Reference [PKIX] should be updated from RFC 3280 to 5280.

Sure.

>- Section 2.23.1, "hve" -> "have"

Done.

--Paul Hoffman, Director
--VPN Consortium

---

From: <[email-masked]>
Date: Mon, 8 Mar 2010 08:16:58 +0100

Paul Hoffman wrote:

> >   In section 1.3.2, changed "The KEi payload SHOULD be included" to
> >   be "The KEi payload MUST be included".  This also led to changes in
> >   section 2.18.
> >
> >and
> >
> Disagree. Where possible, I tried to list the actual sections where
> changes were made, and your proposed rewording loses the two places.
> The current text is more explicit than the proposed change.

Well, this depends on whether you think Section 1.7 should list
textual changes in the document, or clarification/changes to the
protocol.

IMHO, it should be the latter, but I see that currently it's really
listing the textual changes (even when they clearly don't have any
impact on the protocol); so perhaps listing these separately is
consistent with that...

Best regards,
Pasi

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 8 Mar 2010 07:17:33 -0800

>impact on the protocol); so perhaps listing these separately is

The problem with making this list more conceptual (as both you and Tero have requested) is that doing so may help future implementers but can miss context that is important to a current implementer who needs to change their implementation. In this particular example, we have one change that affects two very different parts of the document, and someone who implemented by reading RFC 4306 (instead of knowing it instinctively like you and Tero) might really need to see exactly which bits *of the spec* are changing to decide which bits of their code is changing.

I will try to come up with a way to cover the conceptual change as well, but really am loath to remove the section references in the change description.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 8 Mar 2010 17:08:03 +0200

> impact on the protocol); so perhaps listing these separately is

I agree with you that it should be listing actual clarifications and
changes, not just textual changes. For implementor it does not really
matter what paragraphs were changed, he is interested what changes he
need to do for his implementation and for that the text saying that
Diffie-Hellman is now mandatory when rekeying IKE SA is much more
important than the fact that this changed text in section 1.3.2 and
2.18.

I proposed multiple such changes (including the one you pointed out)
in my email
(http://www.ietf.org/mail-archive/web/ipsec/current/msg05766.html) but
Paul didn't want to make those changes
(http://www.ietf.org/mail-archive/web/ipsec/current/msg05769.html). As
nobody else seemed to care, I didn't continue complaining about the
issue.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 8 Mar 2010 17:43:10 +0200

Paul Hoffman writes:
> The problem with making this list more conceptual (as both you and
> Tero have requested) is that doing so may help future implementers
> but can miss context that is important to a current implementer who
> needs to change their implementation.

As an implementor I disagree with you on that. 

> In this particular example, we have one change that affects two very
> different parts of the document, and someone who implemented by
> reading RFC 4306 (instead of knowing it instinctively like you and
> Tero) might really need to see exactly which bits *of the spec* are
> changing to decide which bits of their code is changing.

Yes that change changes two locations of the text, but only one
location in the implementation. Thus for someone who is doing this
change for their implementation it would be important to understand
that this change is actually just one code change, not two. Also the
change is most likely going to be in the policy enforing part than in
the actual exchange handling code (1.3.2) or the SKEYSEED calculation
part. The implementation simply needs to enforce the IKE SA rekey
policy so that Diffie-Hellman is not optional and that is only change
they need to do in the code. They already have to calculate the
SKEYSEED (most likely with or without the g^ir (new)), and they
already have the code to parse KEi and KEr (generic code). 

> I will try to come up with a way to cover the conceptual change as
> well, but really am loath to remove the section references in the
> change description. 
-- 
[email-masked]

---

From: Raj Singh <[email-masked]>
Date: Sun, 7 Mar 2010 09:13:01 +0530

A Minor Comment:

1. Typo - Section 1 - Introduction - Last Paragraph

   In the description that follows, we assume that no errors occur.
   Modifications to the flow should errors occur are described in
   Section 2.21.
   ------------------------
   In the description that follows, we assume that no errors occur.
   Modifications to the flow *when* errors occur are described in
   Section 2.21.

Best regards,
Raj

On Sat, Mar 6, 2010 at 5:25 PM, <[email-masked]> wrote:

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>