Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.txt

"Valery Smyslov" <svanru@gmail.com> Tue, 04 March 2014 11:02 UTC

Return-Path: <svanru@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 827531A029F for <ipsec@ietfa.amsl.com>; Tue, 4 Mar 2014 03:02:23 -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 4k3E59t69VBA for <ipsec@ietfa.amsl.com>; Tue, 4 Mar 2014 03:02:22 -0800 (PST)
Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AEE2A1A0450 for <ipsec@ietf.org>; Tue, 4 Mar 2014 03:02:21 -0800 (PST)
Received: by mail-lb0-f175.google.com with SMTP id w7so5484869lbi.34 for <ipsec@ietf.org>; Tue, 04 Mar 2014 03:02:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=84POlnXjCYyOHPB5kT5nNlBu4spzVQGlw0JupU9aL6w=; b=ywHtII5k656D85K5bgA1ImkDVkWykWue7oAav6ucybkUYVIvb3wI1dGMX8Bij40eBt vKbdcI62Ese1ma9kzHJnreDchFnQMqr7r1+QMwWYH8xJEVKic2tgFBpV6ZWJS38vg1oQ Gh2k9DTibcqxrDKZs/BbNBrtS5GTAP8mwbWVTCKN46iCst3xmzEe7gyLtYFWVNC5MHM6 pAnaZE7AkOUg6JLFo4DZrcZVoAKopUINuVMP4r0LFT09oiIfQj8pXgzpPeY2HIL+QcfI wtRHaugv6TzJaWWTgEboonRVvb/Msp5adj1Di9TtxYOqv5elJG+r8TjUZHFlF08+pV9I iDlQ==
X-Received: by 10.112.200.201 with SMTP id ju9mr19279lbc.76.1393930937965; Tue, 04 Mar 2014 03:02:17 -0800 (PST)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id q6sm34690960lal.3.2014.03.04.03.02.16 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 04 Mar 2014 03:02:17 -0800 (PST)
Message-ID: <B9EC97E40E784597BA2DF090053A18AB@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Paul Wouters" <paul@nohats.ca>
References: <B1B032692C7045B7AEA06166F8AC9B9F@buildpc> <21268.39396.785431.297271@fireball.kivinen.iki.fi> <01FD5F789A0A406F9CCFC3033EA6721B@buildpc> <alpine.LFD.2.10.1403040450410.1910@bofh.nohats.ca>
Date: Tue, 4 Mar 2014 15:02:34 +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
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/QmZDadP_YmsI2Pu_h8MOeQu4KE4
Cc: ipsec@ietf.org, Tero Kivinen <kivinen@iki.fi>
Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.txt
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: Tue, 04 Mar 2014 11:02:23 -0000

Hi Paul,

>> I agree this may chocke some implementations. The idea was that
>> if implementation notice that Auth Method is NULL, it must
>> not parse ID Payload at all. But I understand that depending
>> on the order in which payloads are processed by particular
>> implementation, this may be inconvinient for implementers.
> 
> I have actually thought about a mode where we scramble the order or
> payloads just to see which implementations would die :P
> 
> No implementation should depend on the order of payloads for anything.

The order payloads are processed is not necessary the order payloads 
appear in the message. Nobody (at least not me) tells that payloads
must be processed in the order they appear in the message,
but you still process payloads in some order. For example,
you first try fo collect all VID payloads too understand what
non-standard things you may expect from the message,
before you start processing other payloads, don't you?

So, I just meant, that if ID Payload is processed before
AUTH Payload (a very natural behaviour, isn't it?), that implementation
may not be prepared to get "scrambled" ID and it may choke it.

But actually, it doesn't matter, because if implementation supports
NULL Auth, it must be prepared to get any ID,
and if it doesn't, then exchange will fail anyway.

>> and require implementations to use it if they want to keep anonimity.
> 
> I feel someone wants to give an implementation the freedom to make an
> unwise decision :P I really want to insist that anonymous means
> anonymous - no methods for sending along an ID.

I just want to allow user to keep his anonimity to the extent
he wishes himself. From my understanding the peer, who uses
NULL Auth, must have freedom to decide whether to
put something in ID (for any reason), or leave it empty. And note, 
that the draft encourages users (by SHOULD) to do the latter.

Regards,
Valery.