Re: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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, <Pasi.Eronen@xxxxxxxxx> wrote:
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
_______________________________________________
IPsec mailing list
IPsec@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]