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

Tero Kivinen <kivinen@iki.fi> Tue, 04 March 2014 10:40 UTC

Return-Path: <kivinen@iki.fi>
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 CEDA51A049D for <ipsec@ietfa.amsl.com>; Tue, 4 Mar 2014 02:40:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 JBxrPXXheOcD for <ipsec@ietfa.amsl.com>; Tue, 4 Mar 2014 02:40:57 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id E6B911A0450 for <ipsec@ietf.org>; Tue, 4 Mar 2014 02:40:56 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s24AenBF020377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Mar 2014 12:40:49 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s24Aen2P000039; Tue, 4 Mar 2014 12:40:49 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21269.44464.979543.950214@fireball.kivinen.iki.fi>
Date: Tue, 4 Mar 2014 12:40:48 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Paul Wouters <paul@nohats.ca>
In-Reply-To: <alpine.LFD.2.10.1403040450410.1910@bofh.nohats.ca>
References: <B1B032692C7045B7AEA06166F8AC9B9F@buildpc> <21268.39396.785431.297271@fireball.kivinen.iki.fi> <01FD5F789A0A406F9CCFC3033EA6721B@buildpc> <alpine.LFD.2.10.1403040450410.1910@bofh.nohats.ca>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 10 min
X-Total-Time: 11 min
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Sk5lE82_BqewJmYEiLn7tmMCU90
Cc: ipsec@ietf.org, Valery Smyslov <svanru@gmail.com>
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 10:40:59 -0000

Paul Wouters writes:
> On Tue, 4 Mar 2014, Valery Smyslov wrote:
> 
> > 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

That only works for RFC5996 version, RFC4306 version are allowed to
reject packets which have payloads in "wrong" order:

>From RFC4306:
----------------------------------------------------------------------
2.5.  Version Numbers and Forward Compatibility
...
   Although new payload types may be added in the future and may appear
   interleaved with the fields defined in this specification,
   implementations MUST send the payloads defined in this specification
   in the order shown in the figures in section 2 and implementations
   SHOULD reject as invalid a message with those payloads in any other
   order.
----------------------------------------------------------------------

RFC5996:
----------------------------------------------------------------------
2.5.  Version Numbers and Forward Compatibility
...
   Although new payload types may be added in the future and may appear
   interleaved with the fields defined in this specification,
   implementations SHOULD send the payloads defined in this
   specification in the order shown in the figures in Sections 1 and 2;
   implementations MUST NOT reject as invalid a message with those
   payloads in any other order.
----------------------------------------------------------------------

> No implementation should depend on the order of payloads for anything.

True, but for example my implementation do parse all payloads first,
and then start processing them by first checking certain payload, then
checking the payloads in suitable order (i.e check that all require
payloads are there, then check whether payloads have suitable values
etc).

This is done just this way so it does not matter in which order the
payloads in the incoming packets are. I will find the ID payload
regardless where it is, when I need it.

And for example my ID parsing code already checks that there must be 4
bytes of data, if the ID type is ID_TYPE_IPV4_ADDR, and will return
error immediately there if that is not true. This is way before I even
start checking what is the authentication type etc.

Of course I could move that checking to later, i.e when actually using
the ID payload, but that would have its own issues. 

> > 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.

This is not anonymous method, this is unauthenticated method. We
cannot really provide anonymity with this method. 

> And I feel that I need to reject anonymous connections that have an ID
> to protect the anonymity of the user.

But should you reject unauthenticated connections just because they
have ID which you are not authenticating anyways. Note, that we are
talking about unauthenticated connections, not really anonymous
connections.
-- 
kivinen@iki.fi