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

"Valery Smyslov" <svanru@gmail.com> Tue, 04 March 2014 06:36 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 873161A027E for <ipsec@ietfa.amsl.com>; Mon, 3 Mar 2014 22:36:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.561
X-Spam-Level:
X-Spam-Status: No, score=-1.561 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, STOX_REPLY_TYPE=0.439] autolearn=no
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 PasWeZ3Jwip1 for <ipsec@ietfa.amsl.com>; Mon, 3 Mar 2014 22:36:47 -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 D8EF31A01AE for <ipsec@ietf.org>; Mon, 3 Mar 2014 22:36:46 -0800 (PST)
Received: by mail-lb0-f175.google.com with SMTP id w7so5248524lbi.6 for <ipsec@ietf.org>; Mon, 03 Mar 2014 22:36:43 -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=xMtnck7NXfp/cD9GaIg8zCEBy+prTTPQ8faRgzNR2kY=; b=s3bxq6K+3pvSmK3m+MM6aShExOHuMFYUOcQZLYvSw/Gut9sJtXoHjkpDJu+rcr3mdh tvOxUpMWeEYSl51MQeWPaq8Q1vaMpXhXmGMU0S5UgaKoS2JA7NmeaeYKcSpehENtxklY loUTK/XdHBakvl+GtL7b3sm04dToJFmshltQDfR+2Kuc+7AI10eWLDDVgp6YWWm1MS2k 6qyG38mOKCoZC6scMSygw/aLFTwIlzZfcMQNP9NLVmRnND3vSXyyWUxUsp2JQA+jVeAb UwnoC1gfPZ5xX2/J2QIFa+jMQg2AXdu7Lzu/CWcTasEiLgcZyWNKd7cts09wBf1DnKV+ S3Sg==
X-Received: by 10.152.3.72 with SMTP id a8mr8464544laa.33.1393914991665; Mon, 03 Mar 2014 22:36:31 -0800 (PST)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id y2sm33737041lal.10.2014.03.03.22.36.30 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 03 Mar 2014 22:36:30 -0800 (PST)
Message-ID: <01FD5F789A0A406F9CCFC3033EA6721B@buildpc>
From: Valery Smyslov <svanru@gmail.com>
To: Tero Kivinen <kivinen@iki.fi>
References: <B1B032692C7045B7AEA06166F8AC9B9F@buildpc> <21268.39396.785431.297271@fireball.kivinen.iki.fi>
Date: Tue, 04 Mar 2014 10:36:44 +0400
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
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/u2IqW08a4hKJFN4K-VeMliHjy5c
Cc: ipsec@ietf.org
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 06:36:48 -0000

Hi Tero, 

> Anyways I think the document is in quite good shape, I think the
> section 2.2 needs to be more specific about how to send the empty ID
> payload. I think the idea of sending ID_IPV4_ADDR with 0 bytes of
> data is very bad idea. The current text says you can omit data, and
> that the type can be anything. The problem is that in most cases the
> implementation has code that will parse the ID payload using standard
> rules and now if the ID payload has type of ID_IPV4_ADDR and 0 bytes
> of data, the parsing will fail.

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.

> It would be better to say that if you are sending empty ID payload,
> you msut use ID_KEY_ID type which already allows any data, including
> empty.

Actually, even with ID_KEY_ID it is a bit of hack.
I'd rather define the entity "Empty ID Payload" as
ID Payload with ID Type of zero and zero-length content
(so that even ID Type be undefined) and require
implementations to use it if they want to keep anonimity.

> Actually I now noticed you changed the "SHOULD be ignored" to "MUST be
> ignored", and I think that is again bad idea. I think logging and
> auditing the ID for problem solving purposes is good idea even if it
> does not have any meaning for the authentication. I.e. at least then I
> can contact helpdesk and say that my NULL authentication connection to
> server 1.2.3.4 failed, and I have no idea why, can you help. Oh, my ID
> payload had ID_KEY_ID 0324234mkdsff43r5, if that helps you to find it
> from your logs... 

Actually, I tried to address Paul Wouters' concern that without
strong "MUST" here implementations may use ID even if it is
not authenticated. But, from my understanding of the wording,
"MUST be ignored by IKE" doesn't mean that implementation
is not allowed to log the ID, that is always useful ror auditing
and troubleshooting. I probably should make this more clear.

Regards,
Valery.

> -- 
> kivinen@iki.fi