[IPsec] Error in RFC6290
"Valery Smyslov" <svanru@gmail.com> Wed, 26 December 2012 06:11 UTC
Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2154921F8C4E for <ipsec@ietfa.amsl.com>; Tue, 25 Dec 2012 22:11:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level:
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-1.299, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLcgcyNxEGic for <ipsec@ietfa.amsl.com>; Tue, 25 Dec 2012 22:11:24 -0800 (PST)
Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3D18B21F8C4C for <ipsec@ietf.org>; Tue, 25 Dec 2012 22:11:23 -0800 (PST)
Received: by mail-la0-f45.google.com with SMTP id p9so10095144laa.4 for <ipsec@ietf.org>; Tue, 25 Dec 2012 22:11:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=mgarpD7UnjDw9LjsevobbL+Js/fD5vd8EHNN8BSkJLU=; b=z7cx9gYGe651I6dszhR+94dk/5se4iasvklwSrqFShvEWp9U4I/zZkohb5iqtpXeGF tmPCNPU3q/rC1hC5iUTJy5G66ua4Go+g2ZHT6qTNtKb6qxYf6bxGOvLPUxq9+voy8NqK mPYgxLR51SP6HAWfhNa2TqfEF/JWL6+vVFCKrE9FpaQNO9FrfHYMDvMJlJRkI+QdrCiK C/8yL6ef580g1rWRumB8hqLijJ/c1Y4JWTqIx/H0y7fCYtGOB/VKxi6mg5aRQeWUE1rS UGjm8kbsu9/3ikYaunlot1qJlNXoeEcP+OWzFXr7SX8trqGn7rl1WfTgkiR79x3Bh5ws 7Qew==
X-Received: by 10.152.111.72 with SMTP id ig8mr24340039lab.1.1356502282772; Tue, 25 Dec 2012 22:11:22 -0800 (PST)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPS id v7sm9144197lbj.13.2012.12.25.22.11.14 (version=SSLv3 cipher=OTHER); Tue, 25 Dec 2012 22:11:21 -0800 (PST)
Message-ID: <DF562289B5D540F095DA9CD3B21AB3D0@buildpc>
From: Valery Smyslov <svanru@gmail.com>
To: ipsec@ietf.org
References: <20121203223404.5441.71025.idtracker@ietfa.amsl.com> <E7FA5DBC7DB747779E6E6D73460A6615@buildpc> <4613980CFC78314ABFD7F85CC30277210EDFD9D0@IL-EX10.ad.checkpoint.com> <B1F8AE12E3604526980FA756C8F2DB09@buildpc>
Date: Wed, 26 Dec 2012 10:11:09 +0400
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="response"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Subject: [IPsec] Error in RFC6290
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 26 Dec 2012 06:11:25 -0000
Hi, RFC6290 (Quick Crash Detection) contains an error. In Section 4.3 it states: For session resumption, as specified in [RFC5723], the situation is similar. The responder, which is necessarily the peer that has crashed, SHOULD send a new ticket within the protected payload of the IKE_SESSION_RESUME exchange. If the Initiator is also a token maker, it needs to send a QCD_TOKEN in a separate INFORMATIONAL exchange. But IKE_SESSION_RESUME exchange, as specified in RFC5723, doesn't contain any protected payload - it is completely in clear and must be followed by IKE_AUTH exchange. I suspect this error came from early versions of IKE SA Resumption protocol that, as far as I remember, did contain protected payload. But currently this para should look like: For session resumption, as specified in [RFC5723], the situation is similar. The responder, which is necessarily the peer that has crashed, SHOULD send a new ticket in IKE_AUTH exchange that immediately followed IKE_SESSION_RESUME exchange. If the Initiator is also a token maker, it needs to send a QCD_TOKEN in the same IKE_AUTH exchange. And one more consideration. In Section 4.1 RFC6290 states: o Protocol ID (1 octet) MUST be 1, as this message is related to an IKE SA. o SPI Size (1 octet) MUST be zero, in conformance with Section 3.10 of [RFC5996]. I think here we have contradiction with RFC5996 (despite clamed conformance with it). In abovementioned Section 3.10 it is written: o Protocol ID (1 octet) - If this notification concerns an existing SA whose SPI is given in the SPI field, this field indicates the type of that SA. For notifications concerning Child SAs, this field MUST contain either (2) to indicate AH or (3) to indicate ESP. Of the notifications defined in this document, the SPI is included only with INVALID_SELECTORS and REKEY_SA. If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt. Let me emphasize that RFC5996 clearly requires that If the SPI field is empty, Protocol ID field MUST be sent as zero and MUST be ignored on receipt, but RFC6290 while requiring SPI field to be empty, requres Protocol ID field to be non-zero. Actually, I see no value in this requirement, as Protocol ID MUST be ignored on receipt anyway (if SPI field is empty), so it just complicates protocol and makes it cumbersome. Merry Christmas, Valery Smyslov.
- [IPsec] I-D Action: draft-ietf-ipsecme-ike-tcp-01… internet-drafts
- Re: [IPsec] I-D Action: draft-ietf-ipsecme-ike-tc… Valery Smyslov
- Re: [IPsec] I-D Action: draft-ietf-ipsecme-ike-tc… Yoav Nir
- Re: [IPsec] I-D Action: draft-ietf-ipsecme-ike-tc… Paul Hoffman
- Re: [IPsec] I-D Action: draft-ietf-ipsecme-ike-tc… Valery Smyslov
- Re: [IPsec] I-D Action: draft-ietf-ipsecme-ike-tc… Paul Wouters
- [IPsec] Error in RFC6290 Valery Smyslov
- Re: [IPsec] Error in RFC6290 Yoav Nir
- Re: [IPsec] Error in RFC6290 Yaron Sheffer
- Re: [IPsec] Error in RFC6290 Valery Smyslov
- Re: [IPsec] Error in RFC6290 Yoav Nir