Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth

Yaron Sheffer <yaronf.ietf@gmail.com> Sat, 28 February 2015 06:24 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF14F1A1BA3 for <ipsec@ietfa.amsl.com>; Fri, 27 Feb 2015 22:24:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LK6MggTBRGNj for <ipsec@ietfa.amsl.com>; Fri, 27 Feb 2015 22:24:54 -0800 (PST)
Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 279C21A1AE8 for <ipsec@ietf.org>; Fri, 27 Feb 2015 22:24:54 -0800 (PST)
Received: by wevk48 with SMTP id k48so24122334wev.0 for <ipsec@ietf.org>; Fri, 27 Feb 2015 22:24:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+ZIY9QUVUwsWZdDiB55EUiZFBm50pLKrttlfKrmp1IQ=; b=qRcepbHoRXStlRcGR6MGIi62yQvuArvGkz+Laxiyp1yL1amAmJdRQlt05AStXp+fQX EnPPKnntcciZDJ4rDGzMfjyZYk/TcxZmHeLJz+hd1km33S93emrg1TJoLUsDdkdxP1WE z2NrZ7il+qddE+RdlfobNro8rjmkW2gUSOEe6CHe8+URUwiuo2F8YYFMB55RGvOe7MJB r3KT/yeBVgSoFUro/pJkJTvrR2WRyAajReZAjuCFZMp8cS1eYtIuwKbqSd2Ce4Dyf2T2 JdvqDTecd0/8R+SwLki0FWRXOJgiUJvzqtjTX8Bz37JJ+wlKTjh2J1DGGhcQHzGXi9B1 L5qg==
X-Received: by 10.180.102.73 with SMTP id fm9mr14171854wib.12.1425104692931; Fri, 27 Feb 2015 22:24:52 -0800 (PST)
Received: from [192.168.1.199] ([109.253.110.54]) by mx.google.com with ESMTPSA id ch6sm8979851wjc.3.2015.02.27.22.24.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Feb 2015 22:24:52 -0800 (PST)
Message-ID: <54F15F31.2090109@gmail.com>
Date: Sat, 28 Feb 2015 08:24:49 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <CAHbuEH6tenb-OG8F0kF5m3RoSdXk3k-AEqjpqNZD-j4iYW6DvQ@mail.gmail.com> <55B72ED0-2A97-4BD5-AFB9-CA71F7FDAAA6@vpnc.org> <54F0E873.2020508@gmail.com> <80906232-2112-40D6-ADBA-95A23137C513@vpnc.org>
In-Reply-To: <80906232-2112-40D6-ADBA-95A23137C513@vpnc.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipsec/B6oW5Z1UjDWQQy_M-mqO_nMdPMQ>
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 28 Feb 2015 06:24:55 -0000

> On Feb 27, 2015, at 1:58 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
>>
>>>
>>> That's a good question, and you can see it both ways.
>>>
>>> - The draft says that the PAD processing in RFC 4301 needs to be updated for this draft, so the draft updates RFC 4301.
>>>
>>> - Implementations of RFC 4301 that do not care about IKEv2 using this draft should not be updated, so this draft doesn't update 4301, just the 4301 processing when using IKEv2 and this draft.
>>>
>>> I tend toward the second interpretation, but am happy either way. What do others think?
>>>
>>> --Paul Hoffman
>>
>> I tend the other way, so we need an example or two. If you read the abstract of RFC 6040, it says: "On decapsulation, [RFC 6040] updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused combinations of inner and outer headers." Which means that even though existing implementations are not affected until they encounter these new message variants, we use "Updates" because new implementations are expected to include the new behavior.
>
> That's an interesting example, one from outside our WG. Note, however, that RFC 6040 is the *only* RFC that updates RFC 4301 so far. It seems odd that it is the only one like this draft that says "and you need to change your PAD processing for this new thing".
>
Similarly, RFC 5282 Updates RFC 4306. Even though you only needed to 
change your implementation if you added AEAD. But it's not very 
important either way.

Thanks,
	Yaron