[IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08
<Pasi.Eronen@nokia.com> Sat, 06 March 2010 11:56 UTC
Return-Path: <Pasi.Eronen@nokia.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D74A3A90BF; Sat, 6 Mar 2010 03:56:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dc0T8M1E3Af0; Sat, 6 Mar 2010 03:56:17 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id BF7E63A8F5C; Sat, 6 Mar 2010 03:56:16 -0800 (PST)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o26Bu14j029255; Sat, 6 Mar 2010 13:56:16 +0200
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Mar 2010 13:55:49 +0200
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Mar 2010 13:55:44 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Mar 2010 13:55:39 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Sat, 6 Mar 2010 12:55:39 +0100
From: Pasi.Eronen@nokia.com
To: ietf@ietf.org, ipsec@ietf.org
Date: Sat, 06 Mar 2010 12:55:37 +0100
Thread-Topic: IETFLC comments for draft-ietf-ipsecme-ikev2bis-08
Thread-Index: Acq9I+7uRCNmSYuURFeQHnq6luW6uw==
Message-ID: <808FD6E27AD4884E94820BC333B2DB7758482FF051@NOK-EUMSG-01.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 06 Mar 2010 11:55:39.0924 (UTC) FILETIME=[F10E6D40:01CABD23]
X-Nokia-AV: Clean
Subject: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Mar 2010 11:56:18 -0000
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] IETFLC comments for draft-ietf-ipsecme-ik… Pasi.Eronen
- Re: [IPsec] IETFLC comments for draft-ietf-ipsecm… Paul Hoffman
- Re: [IPsec] IETFLC comments for draft-ietf-ipsecm… Pasi.Eronen
- Re: [IPsec] IETFLC comments for draft-ietf-ipsecm… Tero Kivinen
- Re: [IPsec] IETFLC comments for draft-ietf-ipsecm… Paul Hoffman
- Re: [IPsec] IETFLC comments for draft-ietf-ipsecm… Tero Kivinen
- [IPsec] IETFLC comments for draft-ietf-ipsecme-ik… Keith Welter
- Re: [IPsec] IETFLC comments for draft-ietf-ipsecm… Yoav Nir
- Re: [IPsec] IETFLC comments for draft-ietf-ipsecm… V Jyothi-B22245