From svanru@gmail.com  Mon Aug  5 05:56:12 2013
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 9C33321F9EEC for <ipsec@ietfa.amsl.com>; Mon,  5 Aug 2013 05:56:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.097
X-Spam-Level: 
X-Spam-Status: No, score=-0.097 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_50=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6XpBt2dksAh for <ipsec@ietfa.amsl.com>; Mon,  5 Aug 2013 05:56:12 -0700 (PDT)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id DD3D521F9EDF for <ipsec@ietf.org>; Mon,  5 Aug 2013 05:56:10 -0700 (PDT)
Received: by mail-lb0-f177.google.com with SMTP id r11so2011601lbv.8 for <ipsec@ietf.org>; Mon, 05 Aug 2013 05:56:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=lla8hdLZx9PSKoirYWwJiqwie03NDaikAdubPZWmMfw=; b=QbUfJ860syL3dudsMfbUlL842/gU2zVI5wiUq04XvBWmhAPKVAgkJrSEqW3BlPNgas 2OZclARIKyVkG7KLAaa5d+LGQobY3l1R2U5lUlUCNHgfP77ZpXaAv6lmn8Z99i7PqIeU VlKepxCmc38j+Trd7ncmoFq4Y/1VCeF5bwWqqF0SQCg1aZnUOaS/LrZxYesy98dlzyu4 62zjBXcZwmBiT2ZZCt18nOoLkxtERB5T7PDyEyZrRHGMhP8Lq7N2Qwjj6UimEvCHC2lK hQI7Ia1C5L0wqB0zYxX6jZHVUm3ZEeQlMDcG+kX4pTuQthcilMtsZj1ls8eYdoplprfA QJ+w==
X-Received: by 10.152.27.9 with SMTP id p9mr8707606lag.4.1375707369665; Mon, 05 Aug 2013 05:56:09 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id q6sm9032234lbv.14.2013.08.05.05.56.07 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 05 Aug 2013 05:56:08 -0700 (PDT)
Message-ID: <8C1AE70F7EB345E6B0207DB11D2377A0@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "yamaya" <yamaya@fnsc.co.jp>, <ipsec@ietf.org>
References: <17835.1375124209@sandelman.ca> <51F7E6FD.8030204@fnsc.co.jp>
Date: Mon, 5 Aug 2013 16:56:08 +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] Replay protection in draft-yamaya-ipsecme-mpsa
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: Mon, 05 Aug 2013 12:56:12 -0000

Hi,

I'd like to reiterate the question, that I asked on the meeting:
how replay protection is supposed to be done in case of multi-point SA?

Regards,
Valery Smyslov.

From paul.hoffman@vpnc.org  Mon Aug  5 06:33:21 2013
Return-Path: <paul.hoffman@vpnc.org>
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 284C421F9EFB for <ipsec@ietfa.amsl.com>; Mon,  5 Aug 2013 06:33:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.956
X-Spam-Level: 
X-Spam-Status: No, score=-101.956 tagged_above=-999 required=5 tests=[AWL=0.643, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fLtPB1zx6n2 for <ipsec@ietfa.amsl.com>; Mon,  5 Aug 2013 06:33:20 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 93DCC21F9ED1 for <ipsec@ietf.org>; Mon,  5 Aug 2013 06:33:20 -0700 (PDT)
Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r75DXJ9e065855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <ipsec@ietf.org>; Mon, 5 Aug 2013 06:33:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228] claimed to be [10.20.30.90]
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <3FFA55C8-0C45-4585-8A5E-71309A800CC1@vpnc.org>
Date: Mon, 5 Aug 2013 06:33:19 -0700
To: IPsecme WG <ipsec@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
X-Mailer: Apple Mail (2.1508)
Subject: [IPsec] Minutes from last week posted
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: Mon, 05 Aug 2013 13:33:21 -0000

See the IPsecME WG area on =
<https://datatracker.ietf.org/meeting/87/materials.html> for both the =
minutes and the slides. Many thanks to Brian Weis for taking minutes!

--Paul Hoffman=

From yamaya@fnsc.co.jp  Wed Aug  7 06:03:58 2013
Return-Path: <yamaya@fnsc.co.jp>
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 6509721F84CD for <ipsec@ietfa.amsl.com>; Wed,  7 Aug 2013 06:03:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.399
X-Spam-Level: *
X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhRgXpicnp1W for <ipsec@ietfa.amsl.com>; Wed,  7 Aug 2013 06:03:53 -0700 (PDT)
Received: from fnsc.co.jp (fnsc.co.jp [114.179.9.192]) by ietfa.amsl.com (Postfix) with ESMTP id 3F01121F99B8 for <ipsec@ietf.org>; Wed,  7 Aug 2013 06:03:52 -0700 (PDT)
Received: from ([158.202.233.182]) by ms.fnsc.co.jp with ESMTP  id 4D8TFN1.1591105; Wed, 07 Aug 2013 22:03:49 +0900
Message-ID: <520245B5.1040607@fnsc.co.jp>
Date: Wed, 07 Aug 2013 22:03:49 +0900
From: yamaya <yamaya@fnsc.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: ipsec@ietf.org
References: <17835.1375124209@sandelman.ca> <51F7E6FD.8030204@fnsc.co.jp> <8C1AE70F7EB345E6B0207DB11D2377A0@buildpc>
In-Reply-To: <8C1AE70F7EB345E6B0207DB11D2377A0@buildpc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [IPsec] Replay protection in draft-yamaya-ipsecme-mpsa
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, 07 Aug 2013 13:03:58 -0000

Thanks for your comment,

Because there are multiple senders for a single multi-point SA, anti-replay is not available, stated in RFC4303. Instead I think that time-based anti-replay, which uses an timestamp value as the sequence number, can be used, however it might be weaker than the normal anti-replay.

Regards,
Arifumi Yamaya,

(2013/08/05 21:56), Valery Smyslov wrote:
> Hi,
>
> I'd like to reiterate the question, that I asked on the meeting:
> how replay protection is supposed to be done in case of multi-point SA?
>
> Regards,
> Valery Smyslov.
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>

From kivinen@iki.fi  Fri Aug  9 06:29:55 2013
Return-Path: <kivinen@iki.fi>
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 3CB2611E80F5 for <ipsec@ietfa.amsl.com>; Fri,  9 Aug 2013 06:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUD45svnL5d3 for <ipsec@ietfa.amsl.com>; Fri,  9 Aug 2013 06:29:54 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 35E9311E8103 for <ipsec@ietf.org>; Fri,  9 Aug 2013 06:29:51 -0700 (PDT)
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 r79DTTSb017330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 9 Aug 2013 16:29:29 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r79DTO3H018812; Fri, 9 Aug 2013 16:29:24 +0300 (EEST)
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: <20996.61108.326911.119416@fireball.kivinen.iki.fi>
Date: Fri, 9 Aug 2013 16:29:24 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: ipsec@ietf.org
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 16 min
X-Total-Time: 30 min
Cc: Pasi Eronen <pe@iki.fi>, turners@ieca.com, Charlie Kaufman <charliek@microsoft.com>, Yoav Nir <ynir@checkpoint.com>, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: [IPsec] First version of RFC5996bis
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: Fri, 09 Aug 2013 13:29:55 -0000

In the last IETF there has been discussion that we should start
driving IPsec protocols from proposed standard to full standard.
Mostly this needs to be done because some other standardization
organizations say they cannot refer to proposed standards, they can
only refer to real standards, and they do not see proposed standards
as real standards.

Sean Turner promised that he would be willing to do the IESG legwork
for this process, but to start that we needed to get the actual
documents ready first. The process of going from proposed standard to
full standards is easier now, but there are still some things we need
to do. The first thing is that we need to take all errata we have for
the document and create a document which fixes that.

To get this process starting I took the RFC5996, and put in the two
errata items we had for that RFC. The submitted the resulting
draft-kivinen-ipsecme-ikev2-rfc5996bis today.

This version only puts in the errata, and a section "Differences
between RFC5996 and This Document".

The problem is that we have been discussing in the WG about the
draft-kivinen-ipsecme-oob-pubkey draft, and that draft currently
obsoletes RAW RSA public keys from the RFC5996 and then adds new one.
We cannot really add new features at this point as it is not widely
implemented or used, but I think we can safely obsolete the RAW RSA
support as it has not been widely used.

So my plan is to make new version of this draft in three weeks time (I
will be vacation for two weeks starting next Monday), and in that
draft obsolete the RAW RSA public keys. After that I will remove all
text about obsoleting the RAW RSA public keys from my
draft-kivinen-ipsecme-oob-pubkey document and it will just be one
normal extension adding stuff to the rfc5996bis.

So if you have any objections for that speak up now...

In addition to the IKEv2, we most likely want to move some other
documents forward too. Some of those are easy like RFC2451 "The ESP
CBC-Mode Cipher Algorithms", RFC3526 "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange", and RFC3986 "UDP
Encapsulation of IPsec ESP Packets", as there is no errata, and they
are widely used.

Some are harder, as we need to make new versions because of errata
(RFC4303 ESP). For some others we need to discuss do we want to make
them forward (AH, MOBIKE etc). But I think discussion about the other
documents should be done on the separate thread, this is just first
step on the road.

----------------------------------------------------------------------
From: internet-drafts@ietf.org
To: "Paul E. Hoffman" <paul.hoffman@vpnc.org>, Pasi Eronen <pe@iki.fi>,
        Charlie Kaufman <charliek@microsoft.com>,
        Tero Kivinen <kivinen@iki.fi>, Yoav Nir <ynir@checkpoint.com>,
        Paul Hoffman <paul.hoffman@vpnc.org>
Subject: New Version Notification for
	draft-kivinen-ipsecme-ikev2-rfc5996bis-00.txt
Date: Fri, 09 Aug 2013 05:49:39 -0700

A new version of I-D, draft-kivinen-ipsecme-ikev2-rfc5996bis-00.txt
has been successfully submitted by Charlie Kaufman and posted to the
IETF repository.

Filename:	 draft-kivinen-ipsecme-ikev2-rfc5996bis
Revision:	 00
Title:		 Internet Key Exchange Protocol Version 2 (IKEv2)
Creation date:	 2013-08-09
Group:		 Individual Submission
Number of pages: 137
URL:             http://www.ietf.org/internet-drafts/draft-kivinen-ipsecme-ikev2-rfc5996bis-00.txt
Status:          http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-ikev2-rfc5996bis
Htmlized:        http://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-rfc5996bis-00


Abstract:
   This document describes version 2 of the Internet Key Exchange (IKE)
   protocol.  IKE is a component of IPsec used for performing mutual
   authentication and establishing and maintaining Security Associations
   (SAs).  This document replaces and updates RFC 4306, and includes all
   of the clarifications from RFC 4718.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
-- 
kivinen@iki.fi

From yaronf.ietf@gmail.com  Fri Aug  9 07:17:02 2013
Return-Path: <yaronf.ietf@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 577EC21F9F7F for <ipsec@ietfa.amsl.com>; Fri,  9 Aug 2013 07:17:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAAWwlbgUI1b for <ipsec@ietfa.amsl.com>; Fri,  9 Aug 2013 07:17:00 -0700 (PDT)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 454E411E80D2 for <ipsec@ietf.org>; Fri,  9 Aug 2013 07:17:00 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id a12so3551011wgh.6 for <ipsec@ietf.org>; Fri, 09 Aug 2013 07:16:54 -0700 (PDT)
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=05ndbUlhV+MUVnYYeYAunnwJFW20g3mvT8BTVzZcuDI=; b=H4wtdTErcOaoi8n4aADQsxRJNp1FEDGJnaIDdyyOyjceu4WeNQ939JWaoR1riEvXyJ 9Z9BDMSdvparsP1BWgJepNd44MEtl13iDr65hBErbqgVkQN4hNHwrtrNHXzs1etFvnoT lQeL5zs3ytkwbLfvQuphzQQ2X4S49KKhKlLnSoFygX04KIYEH0rPDnf3Cix4YK3iHZnh jzZ1YtNQO9kOqxNDmrzlb66MwpVNB/GN/Zm++G7vWjCwSzDR/W3R7kRc5WUkCU5sg1px ai4Cls5dVyoGPWcjnbGO4PXF2utHpbcTE4Shegsvyg+I1B4VJc8V9JiYROQBJV5FjHBE q8ZA==
X-Received: by 10.180.13.174 with SMTP id i14mr531782wic.49.1376057814687; Fri, 09 Aug 2013 07:16:54 -0700 (PDT)
Received: from [10.0.0.3] (bzq-79-180-208-107.red.bezeqint.net. [79.180.208.107]) by mx.google.com with ESMTPSA id a8sm3079317wie.6.2013.08.09.07.16.53 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 07:16:54 -0700 (PDT)
Message-ID: <5204F9B3.8030807@gmail.com>
Date: Fri, 09 Aug 2013 17:16:19 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Tero Kivinen <kivinen@iki.fi>
References: <20996.61108.326911.119416@fireball.kivinen.iki.fi>
In-Reply-To: <20996.61108.326911.119416@fireball.kivinen.iki.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Pasi Eronen <pe@iki.fi>, Charlie Kaufman <charliek@microsoft.com>, Yoav Nir <ynir@checkpoint.com>, Paul Hoffman <paul.hoffman@vpnc.org>, ipsec@ietf.org, turners@ieca.com
Subject: Re: [IPsec] First version of RFC5996bis
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: Fri, 09 Aug 2013 14:17:02 -0000

Hi Tero,

Good stuff! Thanks a lot!

One quick typo: "two Hash and URL format", should be "formats".

Question: RFC 5996 is updated by a single document, which is RFC 5998 
that just got published. The new RFC adds a mandatory, security-critical 
test to IKEv2, and I would like to add to Sec. 1.2 (at the end of the 
paragraph "Both parties in the IKE_AUTH...", this sentence: Both parties 
MUST perform the Diffie-Hellman recipient tests defined in [RFC 5998] 
(and a normative reference). Do you see any issues with that?

Thanks,
     Yaron

On 9.8.2013 16:29, Tero Kivinen wrote:
> In the last IETF there has been discussion that we should start
> driving IPsec protocols from proposed standard to full standard.
> Mostly this needs to be done because some other standardization
> organizations say they cannot refer to proposed standards, they can
> only refer to real standards, and they do not see proposed standards
> as real standards.
>
> Sean Turner promised that he would be willing to do the IESG legwork
> for this process, but to start that we needed to get the actual
> documents ready first. The process of going from proposed standard to
> full standards is easier now, but there are still some things we need
> to do. The first thing is that we need to take all errata we have for
> the document and create a document which fixes that.
>
> To get this process starting I took the RFC5996, and put in the two
> errata items we had for that RFC. The submitted the resulting
> draft-kivinen-ipsecme-ikev2-rfc5996bis today.
>
> This version only puts in the errata, and a section "Differences
> between RFC5996 and This Document".
>
> The problem is that we have been discussing in the WG about the
> draft-kivinen-ipsecme-oob-pubkey draft, and that draft currently
> obsoletes RAW RSA public keys from the RFC5996 and then adds new one.
> We cannot really add new features at this point as it is not widely
> implemented or used, but I think we can safely obsolete the RAW RSA
> support as it has not been widely used.
>
> So my plan is to make new version of this draft in three weeks time (I
> will be vacation for two weeks starting next Monday), and in that
> draft obsolete the RAW RSA public keys. After that I will remove all
> text about obsoleting the RAW RSA public keys from my
> draft-kivinen-ipsecme-oob-pubkey document and it will just be one
> normal extension adding stuff to the rfc5996bis.
>
> So if you have any objections for that speak up now...
>
> In addition to the IKEv2, we most likely want to move some other
> documents forward too. Some of those are easy like RFC2451 "The ESP
> CBC-Mode Cipher Algorithms", RFC3526 "More Modular Exponential (MODP)
> Diffie-Hellman groups for Internet Key Exchange", and RFC3986 "UDP
> Encapsulation of IPsec ESP Packets", as there is no errata, and they
> are widely used.
>
> Some are harder, as we need to make new versions because of errata
> (RFC4303 ESP). For some others we need to discuss do we want to make
> them forward (AH, MOBIKE etc). But I think discussion about the other
> documents should be done on the separate thread, this is just first
> step on the road.
>
> ----------------------------------------------------------------------
> From: internet-drafts@ietf.org
> To: "Paul E. Hoffman" <paul.hoffman@vpnc.org>, Pasi Eronen <pe@iki.fi>,
>          Charlie Kaufman <charliek@microsoft.com>,
>          Tero Kivinen <kivinen@iki.fi>, Yoav Nir <ynir@checkpoint.com>,
>          Paul Hoffman <paul.hoffman@vpnc.org>
> Subject: New Version Notification for
> 	draft-kivinen-ipsecme-ikev2-rfc5996bis-00.txt
> Date: Fri, 09 Aug 2013 05:49:39 -0700
>
> A new version of I-D, draft-kivinen-ipsecme-ikev2-rfc5996bis-00.txt
> has been successfully submitted by Charlie Kaufman and posted to the
> IETF repository.
>
> Filename:	 draft-kivinen-ipsecme-ikev2-rfc5996bis
> Revision:	 00
> Title:		 Internet Key Exchange Protocol Version 2 (IKEv2)
> Creation date:	 2013-08-09
> Group:		 Individual Submission
> Number of pages: 137
> URL:             http://www.ietf.org/internet-drafts/draft-kivinen-ipsecme-ikev2-rfc5996bis-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-ikev2-rfc5996bis
> Htmlized:        http://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-rfc5996bis-00
>
>
> Abstract:
>     This document describes version 2 of the Internet Key Exchange (IKE)
>     protocol.  IKE is a component of IPsec used for performing mutual
>     authentication and establishing and maintaining Security Associations
>     (SAs).  This document replaces and updates RFC 4306, and includes all
>     of the clarifications from RFC 4718.
>
>                                                                                    
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat


From yaronf.ietf@gmail.com  Fri Aug  9 13:31:11 2013
Return-Path: <yaronf.ietf@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 DF1F021F9A8C for <ipsec@ietfa.amsl.com>; Fri,  9 Aug 2013 13:31:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSA6+DrR2DBx for <ipsec@ietfa.amsl.com>; Fri,  9 Aug 2013 13:31:11 -0700 (PDT)
Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4072C21E805A for <ipsec@ietf.org>; Fri,  9 Aug 2013 13:26:06 -0700 (PDT)
Received: by mail-we0-f179.google.com with SMTP id t57so3953078wes.10 for <ipsec@ietf.org>; Fri, 09 Aug 2013 13:26:05 -0700 (PDT)
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=bjU5QIbGD+m2/1E+bTroygnd58k5Zw8jNSYCGtDAphM=; b=q0zK51CQ5Om0Ipjar7/ER8ZNS0xnETvy4jNN5iZGaHLFJRdWzMr8ndEHw1AeFjPypT zKFgnX+XqTQtzPQdJjkGuQvqNBOjziVJkSQJa3bf7/Ux/LJqzBl6qyTLOTIh2wp6nOON u3nrz13yWHxHF/zhNrzuGV4YuHtezUoj180+EnGJVMMJpvX0K/lAmvcWbIHdz2ir1wd6 EUe8mBSh4N8+OAj51ZkuQnudBP9Z65rWvCS9H5We5VOYyJGOMJmn9FhlBnvwQbuPAQRD oJp/QbOp5Mmwke0b6GeNIZJK+OeI7aLE5kgJ6YS1s179zZyIJUjKP545Eg/3V4ust+Bm O64Q==
X-Received: by 10.180.184.107 with SMTP id et11mr1274696wic.60.1376079965301;  Fri, 09 Aug 2013 13:26:05 -0700 (PDT)
Received: from [10.0.0.6] (bzq-79-180-208-107.red.bezeqint.net. [79.180.208.107]) by mx.google.com with ESMTPSA id gg10sm4585473wib.1.2013.08.09.13.26.03 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 13:26:04 -0700 (PDT)
Message-ID: <5205505A.2060607@gmail.com>
Date: Fri, 09 Aug 2013 23:26:02 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: Tero Kivinen <kivinen@iki.fi>
References: <20996.61108.326911.119416@fireball.kivinen.iki.fi> <5204F9B3.8030807@gmail.com>
In-Reply-To: <5204F9B3.8030807@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Pasi Eronen <pe@iki.fi>, Charlie Kaufman <charliek@microsoft.com>, Yoav Nir <ynir@checkpoint.com>, Paul Hoffman <paul.hoffman@vpnc.org>, ipsec@ietf.org, turners@ieca.com
Subject: Re: [IPsec] First version of RFC5996bis
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: Fri, 09 Aug 2013 20:31:12 -0000

Sorry, I meant RFC 6989 (thanks Graham).

	Yaron

On 2013-08-09 17:16, Yaron Sheffer wrote:
> Hi Tero,
>
> Good stuff! Thanks a lot!
>
> One quick typo: "two Hash and URL format", should be "formats".
>
> Question: RFC 5996 is updated by a single document, which is RFC 5998
> that just got published. The new RFC adds a mandatory, security-critical
> test to IKEv2, and I would like to add to Sec. 1.2 (at the end of the
> paragraph "Both parties in the IKE_AUTH...", this sentence: Both parties
> MUST perform the Diffie-Hellman recipient tests defined in [RFC 5998]
> (and a normative reference). Do you see any issues with that?
>
> Thanks,
>      Yaron
>
> On 9.8.2013 16:29, Tero Kivinen wrote:
>> In the last IETF there has been discussion that we should start
>> driving IPsec protocols from proposed standard to full standard.
>> Mostly this needs to be done because some other standardization
>> organizations say they cannot refer to proposed standards, they can
>> only refer to real standards, and they do not see proposed standards
>> as real standards.
>>
>> Sean Turner promised that he would be willing to do the IESG legwork
>> for this process, but to start that we needed to get the actual
>> documents ready first. The process of going from proposed standard to
>> full standards is easier now, but there are still some things we need
>> to do. The first thing is that we need to take all errata we have for
>> the document and create a document which fixes that.
>>
>> To get this process starting I took the RFC5996, and put in the two
>> errata items we had for that RFC. The submitted the resulting
>> draft-kivinen-ipsecme-ikev2-rfc5996bis today.
>>
>> This version only puts in the errata, and a section "Differences
>> between RFC5996 and This Document".
>>
>> The problem is that we have been discussing in the WG about the
>> draft-kivinen-ipsecme-oob-pubkey draft, and that draft currently
>> obsoletes RAW RSA public keys from the RFC5996 and then adds new one.
>> We cannot really add new features at this point as it is not widely
>> implemented or used, but I think we can safely obsolete the RAW RSA
>> support as it has not been widely used.
>>
>> So my plan is to make new version of this draft in three weeks time (I
>> will be vacation for two weeks starting next Monday), and in that
>> draft obsolete the RAW RSA public keys. After that I will remove all
>> text about obsoleting the RAW RSA public keys from my
>> draft-kivinen-ipsecme-oob-pubkey document and it will just be one
>> normal extension adding stuff to the rfc5996bis.
>>
>> So if you have any objections for that speak up now...
>>
>> In addition to the IKEv2, we most likely want to move some other
>> documents forward too. Some of those are easy like RFC2451 "The ESP
>> CBC-Mode Cipher Algorithms", RFC3526 "More Modular Exponential (MODP)
>> Diffie-Hellman groups for Internet Key Exchange", and RFC3986 "UDP
>> Encapsulation of IPsec ESP Packets", as there is no errata, and they
>> are widely used.
>>
>> Some are harder, as we need to make new versions because of errata
>> (RFC4303 ESP). For some others we need to discuss do we want to make
>> them forward (AH, MOBIKE etc). But I think discussion about the other
>> documents should be done on the separate thread, this is just first
>> step on the road.
>>
>> ----------------------------------------------------------------------
>> From: internet-drafts@ietf.org
>> To: "Paul E. Hoffman" <paul.hoffman@vpnc.org>, Pasi Eronen <pe@iki.fi>,
>>          Charlie Kaufman <charliek@microsoft.com>,
>>          Tero Kivinen <kivinen@iki.fi>, Yoav Nir <ynir@checkpoint.com>,
>>          Paul Hoffman <paul.hoffman@vpnc.org>
>> Subject: New Version Notification for
>>     draft-kivinen-ipsecme-ikev2-rfc5996bis-00.txt
>> Date: Fri, 09 Aug 2013 05:49:39 -0700
>>
>> A new version of I-D, draft-kivinen-ipsecme-ikev2-rfc5996bis-00.txt
>> has been successfully submitted by Charlie Kaufman and posted to the
>> IETF repository.
>>
>> Filename:     draft-kivinen-ipsecme-ikev2-rfc5996bis
>> Revision:     00
>> Title:         Internet Key Exchange Protocol Version 2 (IKEv2)
>> Creation date:     2013-08-09
>> Group:         Individual Submission
>> Number of pages: 137
>> URL:
>> http://www.ietf.org/internet-drafts/draft-kivinen-ipsecme-ikev2-rfc5996bis-00.txt
>>
>> Status:
>> http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-ikev2-rfc5996bis
>> Htmlized:
>> http://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-rfc5996bis-00
>>
>>
>> Abstract:
>>     This document describes version 2 of the Internet Key Exchange (IKE)
>>     protocol.  IKE is a component of IPsec used for performing mutual
>>     authentication and establishing and maintaining Security Associations
>>     (SAs).  This document replaces and updates RFC 4306, and includes all
>>     of the clarifications from RFC 4718.
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>

From yaronf.ietf@gmail.com  Mon Aug 12 11:56:38 2013
Return-Path: <yaronf.ietf@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 B33AE21F9991 for <ipsec@ietfa.amsl.com>; Mon, 12 Aug 2013 11:56:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1XBkd-HK7q2 for <ipsec@ietfa.amsl.com>; Mon, 12 Aug 2013 11:56:38 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id F0FE821F996A for <ipsec@ietf.org>; Mon, 12 Aug 2013 11:56:37 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id j17so2097345wiw.11 for <ipsec@ietf.org>; Mon, 12 Aug 2013 11:56:37 -0700 (PDT)
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:subject :content-type:content-transfer-encoding; bh=2fiULqVVAMIrEU65CfqH38SwG1G2N3jQ/gBeY+ePYhs=; b=rmJsMCmJxsfNntW4//n1BCNLhKKEzzkTrpVeMmb9+mGDvKoSTW53OuziwWImviZy1Y kqGqg+A5wOl6AZp3Pesc9j2Zcn1kMs/pcdHLiKBrQfw4sUjAMIoxEj6cRvpclJwMyl6w 5+gLz3yZLKEdTJmM8hWpJFsKd1YBRcM2EHY93YH7CKgtsMW6yIIf+rloVnqhYt3d4swu 3Mmeu2LtGhQ9nOocFWr42dN8JFTv7MTXVepV7RfNJa5v3Ox4Sg4Qy48RB4OWkr3AQBYK J0rgiwz3iwEMbp2aYdBSePV3WuuGLPVSPOD12MdH698VWCbHmnQw75ub/dZUb+rjjtmv 7Qug==
X-Received: by 10.194.89.233 with SMTP id br9mr305226wjb.15.1376333797082; Mon, 12 Aug 2013 11:56:37 -0700 (PDT)
Received: from [10.0.0.6] (bzq-79-180-208-107.red.bezeqint.net. [79.180.208.107]) by mx.google.com with ESMTPSA id n2sm18090556wiz.4.2013.08.12.11.56.34 for <ipsec@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Aug 2013 11:56:36 -0700 (PDT)
Message-ID: <52092FD5.70809@gmail.com>
Date: Mon, 12 Aug 2013 21:56:21 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: IPsecme WG <ipsec@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [IPsec] Starting the discussion on AD VPN protocol proposals
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: Mon, 12 Aug 2013 18:56:38 -0000

Hi,

We would like to start the discussion in a week's time (Aug. 19) on the 
mailing list, followed by a virtual interim meeting about 2 weeks later.

To do that, we need all proposals to include a comparison with the 
requirements of the Problem Statement draft. The only proposal that's 
totally missing such a comparison is draft-mao-ipsecme-ad-vpn-protocol. 
Authors, please make sure to update your drafts to include such a 
section (or anything else that you deem necessary for the initial 
discussion) before August 19.

Also, authors are strongly encouraged to follow the (experimental, 
non-mandatory) RFC 6982.

Thanks,
     Paul and Yaron

From turners@ieca.com  Mon Aug 12 13:44:15 2013
Return-Path: <turners@ieca.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 A3FE921F9D4A for <ipsec@ietfa.amsl.com>; Mon, 12 Aug 2013 13:44:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.728
X-Spam-Level: 
X-Spam-Status: No, score=-101.728 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsdOY9pKOp47 for <ipsec@ietfa.amsl.com>; Mon, 12 Aug 2013 13:44:10 -0700 (PDT)
Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [67.18.124.12]) by ietfa.amsl.com (Postfix) with ESMTP id 980E521F9ADF for <ipsec@ietf.org>; Mon, 12 Aug 2013 13:44:10 -0700 (PDT)
Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id C48FFF99F7653; Mon, 12 Aug 2013 15:43:18 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway09.websitewelcome.com (Postfix) with ESMTP id B48A8F99F7615 for <ipsec@ietf.org>; Mon, 12 Aug 2013 15:43:18 -0500 (CDT)
Received: from [96.231.225.44] (port=54469 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <turners@ieca.com>) id 1V8yyH-00023Y-AC for ipsec@ietf.org; Mon, 12 Aug 2013 15:44:09 -0500
Message-ID: <52094918.70808@ieca.com>
Date: Mon, 12 Aug 2013 16:44:08 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: ipsec@ietf.org
References: <20130606184042.75CE962124@rfc-editor.org>
In-Reply-To: <20130606184042.75CE962124@rfc-editor.org>
X-Forwarded-Message-Id: <20130606184042.75CE962124@rfc-editor.org>
Content-Type: multipart/mixed; boundary="------------020409010805010406090006"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (thunderfish.local) [96.231.225.44]:54469
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 4
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Subject: [IPsec] Fwd: [Technical Errata Reported] RFC4543 (3643)
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: Mon, 12 Aug 2013 20:44:15 -0000

This is a multi-part message in MIME format.
--------------020409010805010406090006
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thoughts?

spt

-------- Original Message --------
Subject: [Technical Errata Reported] RFC4543 (3643)
Date: Thu,  6 Jun 2013 11:40:42 -0700 (PDT)
From: RFC Errata System <rfc-editor@rfc-editor.org>
To: mcgrew@cisco.com, viega@list.org, iesg@ietf.org
CC: rfc-editor@rfc-editor.org, mbowler@elliptictech.com

The following errata report has been submitted for RFC4543,
"The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4543&eid=3643

--------------------------------------
Type: Technical
Reported by: Michael Bowler <mbowler@elliptictech.com>

Section: 4

Original Text
-------------
    In AUTH_AES_GMAC, the AH Authentication Data field consists of the IV
    and the Authentication Tag, as shown in Figure 5.  Unlike the usual
    AH case, the Authentication Data field contains both an input to the
    authentication algorithm (the IV) and the output of the
    authentication algorithm (the tag).  No padding is required in the
    Authentication Data field, because its length is a multiple of 64
    bits.

Corrected Text
--------------
    In AUTH_AES_GMAC, the AH Authentication Data field consists of the IV
    and the Authentication Tag, as shown in Figure 5.  Unlike the usual
    AH case, the Authentication Data field contains both an input to the
    authentication algorithm (the IV) and the output of the
    authentication algorithm (the tag).  In IPv6, padding of 4 octets is
    required to bring the AH header to a multiple of 64-bits.  No padding
    is required for IPv4.

Notes
-----
The original text fails to consider the rest of the AH header which is 
12 octets plus the authentication data field.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC4543 (draft-mcgrew-aes-gmac-esp-02)
--------------------------------------
Title               : The Use of Galois Message Authentication Code 
(GMAC) in IPsec ESP and AH
Publication Date    : May 2006
Author(s)           : D. McGrew, J. Viega
Category            : PROPOSED STANDARD
Source              : IETF - NON WORKING GROUP
Area                : N/A
Stream              : IETF
Verifying Party     : IESG




--------------020409010805010406090006
Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0";
 name="Attached Message Part"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="Attached Message Part"


--------------020409010805010406090006--

From mcr@sandelman.ca  Mon Aug 12 18:13:14 2013
Return-Path: <mcr@sandelman.ca>
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 375B111E80FF for <ipsec@ietfa.amsl.com>; Mon, 12 Aug 2013 18:13:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.523
X-Spam-Level: 
X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMtJHpvOY5I9 for <ipsec@ietfa.amsl.com>; Mon, 12 Aug 2013 18:13:08 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF0F11E8104 for <ipsec@ietf.org>; Mon, 12 Aug 2013 18:13:01 -0700 (PDT)
Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9BE9720170; Mon, 12 Aug 2013 22:19:46 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 0FA0563AB6; Mon, 12 Aug 2013 21:11:26 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id ECF1263AB2; Mon, 12 Aug 2013 21:11:26 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Sean Turner <turners@ieca.com>
In-Reply-To: <52094918.70808@ieca.com>
References: <20130606184042.75CE962124@rfc-editor.org> <52094918.70808@ieca.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 12 Aug 2013 21:11:26 -0400
Message-ID: <1261.1376356286@sandelman.ca>
Sender: mcr@sandelman.ca
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Fwd: [Technical Errata Reported] RFC4543 (3643)
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: Tue, 13 Aug 2013 01:13:14 -0000

--=-=-=


Sean Turner <turners@ieca.com> wrote:
    > --------------------------------------
    > Type: Technical
    > Reported by: Michael Bowler <mbowler@elliptictech.com>

    > Section: 4

    > Original Text
    > -------------
    > In AUTH_AES_GMAC, the AH Authentication Data field consists of the IV
    > and the Authentication Tag, as shown in Figure 5.  Unlike the usual
    > AH case, the Authentication Data field contains both an input to the
    > authentication algorithm (the IV) and the output of the
    > authentication algorithm (the tag).  No padding is required in the
    > Authentication Data field, because its length is a multiple of 64
    > bits.

    > Corrected Text
    > --------------
    > In AUTH_AES_GMAC, the AH Authentication Data field consists of the IV
    > and the Authentication Tag, as shown in Figure 5.  Unlike the usual
    > AH case, the Authentication Data field contains both an input to the
    > authentication algorithm (the IV) and the output of the
    > authentication algorithm (the tag).  In IPv6, padding of 4 octets is
    > required to bring the AH header to a multiple of 64-bits.  No padding
    > is required for IPv4.

I see. Sounds reasonable.
Too bad the AES_GMAC designers didn't truncate more.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works



--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQCVAwUBUgmHvIqHRg3pndX9AQKxzgQA607hJnhAjRtWuRpeHIFwoGc4hahgglOO
9HIF4Ds/dcia3kbOj82Q/K/wPEDBx7V9Us6s5LWc1YXoBkFgtzjE8BT7+O/VBqsF
TLO5XPL9lJMZEEk7DfPRrfummBmbcmq1wjHDA4Qi5YHJZMmj4PemmmwPB83FIAhq
jW35BzLVvwQ=
=l+zA
-----END PGP SIGNATURE-----
--=-=-=--

From ynir@checkpoint.com  Tue Aug 13 13:30:03 2013
Return-Path: <ynir@checkpoint.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 47D3E11E81C0 for <ipsec@ietfa.amsl.com>; Tue, 13 Aug 2013 13:30:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiXtYuAChznt for <ipsec@ietfa.amsl.com>; Tue, 13 Aug 2013 13:29:58 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 29C6211E81B7 for <ipsec@ietf.org>; Tue, 13 Aug 2013 13:29:57 -0700 (PDT)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7DKTunX006635 for <ipsec@ietf.org>; Tue, 13 Aug 2013 23:29:56 +0300
X-CheckPoint: {520A9744-0-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Tue, 13 Aug 2013 23:29:55 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: "<ipsec@ietf.org> WG" <ipsec@ietf.org>
Thread-Topic: I-D Action: draft-nir-ipsecme-cafr-00.txt
Thread-Index: AQHOl6wRkkEDfWWeVUauNy8L9JO2Ag==
Date: Tue, 13 Aug 2013 20:30:01 +0000
Message-ID: <482E5FF2-2AD7-469B-9679-A5945E609A5F@checkpoint.com>
References: <20130812223310.2768.80108.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.178]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
x-cpdlp: 112eabf7d433a5e03b75d1bbf118b8a74b00a07491
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D8EB86B55422D74A9E3FAF2275CA28CB@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [IPsec] Fwd: I-D Action: draft-nir-ipsecme-cafr-00.txt
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: Tue, 13 Aug 2013 20:30:03 -0000

Hi all

For a long time I've felt that re-authentication in IKEv2 has some harsh si=
de effects in both uninterrupted IPsec and in continuation of the internal =
IP address assignment.

This draft attempts  to solve these issues.

Comments are welcome, and I will be glad if the WG agrees to discuss and ad=
opt this.

Thanks

Yoav

> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>=20
>=20
> 	Title           : Adopting Child SAs Following Re-Authentication in IKEv=
2
> 	Author(s)       : Yoav Nir
> 	Filename        : draft-nir-ipsecme-cafr-00.txt
> 	Pages           : 8
> 	Date            : 2013-08-12
>=20
> Abstract:
>   This document describes an extension to the IKEv2 protocol whereby
>   Child SAs are moved to the new IKE SA following re-authentication.
>   This allows for a smoother transition with no loss of connectivity.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-nir-ipsecme-cafr
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-nir-ipsecme-cafr-00
>=20
>=20
> Please note that it may take a couple of minutes from the time of submiss=
ion
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/


From paul.hoffman@vpnc.org  Tue Aug 13 20:38:24 2013
Return-Path: <paul.hoffman@vpnc.org>
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 33F0311E818A for <ipsec@ietfa.amsl.com>; Tue, 13 Aug 2013 20:38:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.49
X-Spam-Level: 
X-Spam-Status: No, score=-101.49 tagged_above=-999 required=5 tests=[AWL=-1.110, BAYES_00=-2.599, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1Z+bEcGWq07 for <ipsec@ietfa.amsl.com>; Tue, 13 Aug 2013 20:38:23 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4423D11E8116 for <ipsec@ietf.org>; Tue, 13 Aug 2013 20:38:23 -0700 (PDT)
Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r7E3cKN1002788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <ipsec@ietf.org>; Tue, 13 Aug 2013 20:38:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90]
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <78CEB7EF-8421-46DF-A685-3DDBA344904A@vpnc.org>
Date: Tue, 13 Aug 2013 20:38:20 -0700
To: IPsecme WG <ipsec@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
X-Mailer: Apple Mail (2.1508)
Subject: [IPsec] IPR statement from Cisco regarding draft-detienne-dmvpn
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, 14 Aug 2013 03:38:24 -0000

See https://datatracker.ietf.org/ipr/2173/



From svanru@gmail.com  Wed Aug 14 02:52:31 2013
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 102FF21E808E for <ipsec@ietfa.amsl.com>; Wed, 14 Aug 2013 02:52:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJ-abfHicUCo for <ipsec@ietfa.amsl.com>; Wed, 14 Aug 2013 02:52:30 -0700 (PDT)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 19A5D11E811E for <ipsec@ietf.org>; Wed, 14 Aug 2013 02:52:29 -0700 (PDT)
Received: by mail-la0-f47.google.com with SMTP id eo20so6640484lab.20 for <ipsec@ietf.org>; Wed, 14 Aug 2013 02:52:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=E1kTMWr2OnCp/aRpZ+sfEbsr95RcKciIGSslg2wnfMQ=; b=b9D2x8caA8YOtB8q0ISApU9GaGBm+TQX01n+SnC7SwbtE0vr7hu+Ua9qTxirWAKIns 0mO5Kxpu0zR1FBVLGy2fJqhzxslOg9f+P0sYwI7iA6fJHb0KaJQzghzIOmXZW4B9KvSC bqiQuNnOaNWbdwSNPtDtK/D9LRErx4muqarY9Wh0N3XX4ueT5sKxhHGblF8I5p3ZwSSq YdaMnfabm45pdp3DgtAe5o5VdfeTx/iR6s0QAXkAiFmFtBEkCRZWx1LlzEayLCxoeHYX 4Ftca0ZHg/KIJK9BOxWq3Vpm60J5Yi8JsYCUeyQbRDZv9HxG6qqLfFzRQ5aiKmMvVB+X 5alQ==
X-Received: by 10.152.8.51 with SMTP id o19mr588744laa.42.1376473948773; Wed, 14 Aug 2013 02:52:28 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id rd5sm15498154lbb.16.2013.08.14.02.52.27 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 14 Aug 2013 02:52:27 -0700 (PDT)
Message-ID: <69110CB5C30743C4A03CCAB62F7D9843@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Yoav Nir" <ynir@checkpoint.com>, <ipsec@ietf.org>
References: <20130812223310.2768.80108.idtracker@ietfa.amsl.com> <482E5FF2-2AD7-469B-9679-A5945E609A5F@checkpoint.com>
Date: Wed, 14 Aug 2013 13:52:29 +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
Subject: Re: [IPsec] Fwd: I-D Action: draft-nir-ipsecme-cafr-00.txt
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, 14 Aug 2013 09:52:31 -0000

Hi Yoav,

isn't it better to do Child SAs movement in a separate Informational 
Exchange,
rather than in IKE_AUTH?

Pros:
1. No race conditions
2. No additional complication to already over-complicated IKE_AUTH
3. More generic solution, so can be used in other situations,
    for example in case IKA SA is cloned 
(draft-mglt-ipsecme-keep-old-ike-sa).

Contras:
1. Extra round trip.

Regards,
Valery Smyslov.

> Hi all
>
> For a long time I've felt that re-authentication in IKEv2 has some harsh 
> side effects in both uninterrupted IPsec and in continuation of the 
> internal IP address assignment.
>
> This draft attempts  to solve these issues.
>
> Comments are welcome, and I will be glad if the WG agrees to discuss and 
> adopt this.
>
> Thanks
>
> Yoav
>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>>
>>
>> Title           : Adopting Child SAs Following Re-Authentication in IKEv2
>> Author(s)       : Yoav Nir
>> Filename        : draft-nir-ipsecme-cafr-00.txt
>> Pages           : 8
>> Date            : 2013-08-12
>>
>> Abstract:
>>   This document describes an extension to the IKEv2 protocol whereby
>>   Child SAs are moved to the new IKE SA following re-authentication.
>>   This allows for a smoother transition with no loss of connectivity.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-nir-ipsecme-cafr
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-nir-ipsecme-cafr-00
>>
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec 


From svanru@gmail.com  Wed Aug 14 07:07:20 2013
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 F249C21E8097 for <ipsec@ietfa.amsl.com>; Wed, 14 Aug 2013 07:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTFJEIlz41cJ for <ipsec@ietfa.amsl.com>; Wed, 14 Aug 2013 07:07:15 -0700 (PDT)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 498F311E816B for <ipsec@ietf.org>; Wed, 14 Aug 2013 07:06:59 -0700 (PDT)
Received: by mail-la0-f49.google.com with SMTP id ev20so6808572lab.36 for <ipsec@ietf.org>; Wed, 14 Aug 2013 07:06:58 -0700 (PDT)
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=8IuSw7Dnoa1SkBMkpwQ+Ry5Cz5QcHz8eAPZgfRuiOLw=; b=gkGcelZcnLl4EDXPalxKn+103FZmzASktMp9YefXflUmwdAae2rRZUn9zyezBZI8Q7 AVlLuqOwmTShLxnHEoHiAqy1sl681SSI9HWbG3wLLtb4gVRF804Hinj6Idx+OY4HQkIf /nE6a65bge6HRr9m+woLCfR/iEiMQY7HLLDifaf9fOk0hI5IQTiJhJLIXjKJcUTklega VpvpD5M1Xrt4zUWW0uuT1hhn7eyRc++/DbS4xVjGTKNwfQLl8giCfmHTt9jwoq9nH9SI G5J35IhI/kQXpX8aY35hph13ISeRHyulv6qKoYnpRtzAS1S4lcYXajvUzvFwNcqwh26B etsg==
X-Received: by 10.152.9.37 with SMTP id w5mr8742789laa.23.1376489218164; Wed, 14 Aug 2013 07:06:58 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id i9sm15962710lba.0.2013.08.14.07.06.56 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 14 Aug 2013 07:06:57 -0700 (PDT)
Message-ID: <FE4D58425F5943FBBFA3AEF73D8951C5@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Yoav Nir" <ynir@checkpoint.com>
References: <20130812223310.2768.80108.idtracker@ietfa.amsl.com> <482E5FF2-2AD7-469B-9679-A5945E609A5F@checkpoint.com> <69110CB5C30743C4A03CCAB62F7D9843@buildpc> <587E0A87-381F-4950-A495-CC8F1706DE7E@checkpoint.com>
Date: Wed, 14 Aug 2013 18:07:02 +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
Cc: ipsec@ietf.org
Subject: Re: [IPsec] I-D Action: draft-nir-ipsecme-cafr-00.txt
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, 14 Aug 2013 14:07:21 -0000

>> isn't it better to do Child SAs movement in a separate Informational 
>> Exchange,
>> rather than in IKE_AUTH?
>>
>> Pros:
>> 1. No race conditions
>
>You would then have three operations that you need to do:
> a. Re-authenticate - create a new IKE SA
> b. Move the IPsec SAs
> c. Delete the old IKE SA
>
> Each of (b) and (c) could be done by any peer, not necessarily the same 
> one that did (a). If we get a DELETE before all the IPsec SAs
> were transferred, some SAs could be deleted, or worse - they could be 
> deleted on only one peer.

Well, similar race conditions are already existed in IKEv2 and are covered
in section 2.25. And I believe, if you properly describe all possible 
collisions and
due actions, those situations, when some SAs are transferred and some not 
etc.
will not happen. Note, that code to deal with collisions according with 2.25
is already in IKEv2, you need only to update conditions to send 
TEMPORARY_FAILURE
notification.

>> 2. No additional complication to already over-complicated IKE_AUTH
>
>It adds one more thing for the peers to do during IKE_AUTH, but it doesn't 
>make a difference if the extra thing is within IKE_AUTH or
>immediately after. If the issue is the length of the packet, I believe we 
>are already solving this.

No, size is not an issue here. But complexity of processing logic for 
IKE_AUTH is an issue.

>> 3. More generic solution, so can be used in other situations,
>>   for example in case IKA SA is cloned 
>> (draft-mglt-ipsecme-keep-old-ike-sa).
>
> Interesting point. That draft does not, in fact, state what happens to the 
> child SAs. Since the old SA is kept, I guess they remain, and when
> the old IKE SA does eventually get deleted, the child SAs are also 
> deleted. Nor does it help to specify that they move: the new IKE SA
> might get deleted first.

I remember the author was asked at the meeting what to do with child SAs,
and he answrered that ability to move them is the next step, that is not 
covered in the current
version of the draft (if I got it right).


From ynir@checkpoint.com  Wed Aug 14 07:30:05 2013
Return-Path: <ynir@checkpoint.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 F38C611E8175 for <ipsec@ietfa.amsl.com>; Wed, 14 Aug 2013 07:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62K8YdiK2HfC for <ipsec@ietfa.amsl.com>; Wed, 14 Aug 2013 07:29:58 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A7D2C11E8166 for <ipsec@ietf.org>; Wed, 14 Aug 2013 07:29:47 -0700 (PDT)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7EDOwdn005721; Wed, 14 Aug 2013 16:24:58 +0300
X-CheckPoint: {520B852A-0-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Wed, 14 Aug 2013 16:24:57 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Valery Smyslov <svanru@gmail.com>
Thread-Topic: [IPsec] I-D Action: draft-nir-ipsecme-cafr-00.txt
Thread-Index: AQHOmPGrxZY+CIrhHk+QOWo1456QUg==
Date: Wed, 14 Aug 2013 13:24:56 +0000
Message-ID: <587E0A87-381F-4950-A495-CC8F1706DE7E@checkpoint.com>
References: <20130812223310.2768.80108.idtracker@ietfa.amsl.com> <482E5FF2-2AD7-469B-9679-A5945E609A5F@checkpoint.com> <69110CB5C30743C4A03CCAB62F7D9843@buildpc>
In-Reply-To: <69110CB5C30743C4A03CCAB62F7D9843@buildpc>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [91.90.139.159]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
x-cpdlp: 11bc3e95c5cf29653e45d6ae696f51d0ec0a7d9ac3
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <FF423AB805B72143B2C9AF9E11F4A7B4@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<ipsec@ietf.org>" <ipsec@ietf.org>
Subject: Re: [IPsec] I-D Action: draft-nir-ipsecme-cafr-00.txt
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, 14 Aug 2013 14:30:05 -0000

On Aug 14, 2013, at 12:52 PM, Valery Smyslov <svanru@gmail.com> wrote:

> Hi Yoav,
>=20
> isn't it better to do Child SAs movement in a separate Informational Exch=
ange,
> rather than in IKE_AUTH?
>=20
> Pros:
> 1. No race conditions

You would then have three operations that you need to do:
 a. Re-authenticate - create a new IKE SA
 b. Move the IPsec SAs
 c. Delete the old IKE SA

Each of (b) and (c) could be done by any peer, not necessarily the same one=
 that did (a). If we get a DELETE before all the IPsec SAs were transferred=
, some SAs could be deleted, or worse - they could be deleted on only one p=
eer.

> 2. No additional complication to already over-complicated IKE_AUTH

It adds one more thing for the peers to do during IKE_AUTH, but it doesn't =
make a difference if the extra thing is within IKE_AUTH or immediately afte=
r. If the issue is the length of the packet, I believe we are already solvi=
ng this.

> 3. More generic solution, so can be used in other situations,
>   for example in case IKA SA is cloned (draft-mglt-ipsecme-keep-old-ike-s=
a).

Interesting point. That draft does not, in fact, state what happens to the =
child SAs. Since the old SA is kept, I guess they remain, and when the old =
IKE SA does eventually get deleted, the child SAs are also deleted. Nor doe=
s it help to specify that they move: the new IKE SA might get deleted first=
.

> Contras:
> 1. Extra round trip.
>=20
> Regards,
> Valery Smyslov.


From ynir@checkpoint.com  Wed Aug 14 14:40:24 2013
Return-Path: <ynir@checkpoint.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 62AEB11E8189 for <ipsec@ietfa.amsl.com>; Wed, 14 Aug 2013 14:40:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.528
X-Spam-Level: 
X-Spam-Status: No, score=-10.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORds29Cn+7me for <ipsec@ietfa.amsl.com>; Wed, 14 Aug 2013 14:40:16 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC1921F9A34 for <ipsec@ietf.org>; Wed, 14 Aug 2013 14:40:11 -0700 (PDT)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7ELe825032420; Thu, 15 Aug 2013 00:40:08 +0300
X-CheckPoint: {520BF938-3-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Thu, 15 Aug 2013 00:40:07 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Valery Smyslov <svanru@gmail.com>
Thread-Topic: [IPsec] I-D Action: draft-nir-ipsecme-cafr-00.txt
Thread-Index: AQHOmPGrxZY+CIrhHk+QOWo1456QUpmUvTiigABMSAA=
Date: Wed, 14 Aug 2013 21:40:07 +0000
Message-ID: <3534574F-9683-49C3-A583-5FEDC05F839B@checkpoint.com>
References: <20130812223310.2768.80108.idtracker@ietfa.amsl.com> <482E5FF2-2AD7-469B-9679-A5945E609A5F@checkpoint.com> <69110CB5C30743C4A03CCAB62F7D9843@buildpc> <587E0A87-381F-4950-A495-CC8F1706DE7E@checkpoint.com> <FE4D58425F5943FBBFA3AEF73D8951C5@buildpc>
In-Reply-To: <FE4D58425F5943FBBFA3AEF73D8951C5@buildpc>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.77]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
x-cpdlp: 11c70d9a6d65cb7677ca18b02951cdfc9cdbb5dfeb
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <C07CC5CEC0E96C49A5D68C252DD19797@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<ipsec@ietf.org>" <ipsec@ietf.org>
Subject: Re: [IPsec] I-D Action: draft-nir-ipsecme-cafr-00.txt
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, 14 Aug 2013 21:40:24 -0000

Thinking it over, there is one significant advantage to what you're proposi=
ng. Suppose our exchanges are like this:

 1. IKE_INITIAL exchange
 2. IKE_AUTH exchange (for re-authentication)
 3. IKE Informational (for moving the Child SAs)
 4. IKE Informational (for deleting the old IKE SA)

#3 can then be run over the old IKE SA. The notification will have the IKE =
SPIs of the new IKE SA. And this makes the crypto unnecessary - the Notific=
ation could be simple the IKE SPIs, and the only verification necessary is =
that the authenticated identity is the same. We could even unify #3 and #4 =
into a single Informational, but it should be the initiator of the new IKE =
SA that sends it.

I think I like that suggestion.

Yoav
=20
On Aug 14, 2013, at 5:07 PM, Valery Smyslov <svanru@gmail.com> wrote:

>>> isn't it better to do Child SAs movement in a separate Informational Ex=
change,
>>> rather than in IKE_AUTH?
>>>=20
>>> Pros:
>>> 1. No race conditions
>>=20
>> You would then have three operations that you need to do:
>> a. Re-authenticate - create a new IKE SA
>> b. Move the IPsec SAs
>> c. Delete the old IKE SA
>>=20
>> Each of (b) and (c) could be done by any peer, not necessarily the same =
one that did (a). If we get a DELETE before all the IPsec SAs
>> were transferred, some SAs could be deleted, or worse - they could be de=
leted on only one peer.
>=20
> Well, similar race conditions are already existed in IKEv2 and are covere=
d
> in section 2.25. And I believe, if you properly describe all possible col=
lisions and
> due actions, those situations, when some SAs are transferred and some not=
 etc.
> will not happen. Note, that code to deal with collisions according with 2=
.25
> is already in IKEv2, you need only to update conditions to send TEMPORARY=
_FAILURE
> notification.
>=20
>>> 2. No additional complication to already over-complicated IKE_AUTH
>>=20
>> It adds one more thing for the peers to do during IKE_AUTH, but it doesn=
't make a difference if the extra thing is within IKE_AUTH or
>> immediately after. If the issue is the length of the packet, I believe w=
e are already solving this.
>=20
> No, size is not an issue here. But complexity of processing logic for IKE=
_AUTH is an issue.
>=20
>>> 3. More generic solution, so can be used in other situations,
>>>  for example in case IKA SA is cloned (draft-mglt-ipsecme-keep-old-ike-=
sa).
>>=20
>> Interesting point. That draft does not, in fact, state what happens to t=
he child SAs. Since the old SA is kept, I guess they remain, and when
>> the old IKE SA does eventually get deleted, the child SAs are also delet=
ed. Nor does it help to specify that they move: the new IKE SA
>> might get deleted first.
>=20
> I remember the author was asked at the meeting what to do with child SAs,
> and he answrered that ability to move them is the next step, that is not =
covered in the current
> version of the draft (if I got it right).
>=20
>=20
> Email secured by Check Point


From ynir@checkpoint.com  Tue Aug 20 20:47:13 2013
Return-Path: <ynir@checkpoint.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 230FF11E81B2 for <ipsec@ietfa.amsl.com>; Tue, 20 Aug 2013 20:47:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.718
X-Spam-Level: 
X-Spam-Status: No, score=-10.718 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnsi5wso08aY for <ipsec@ietfa.amsl.com>; Tue, 20 Aug 2013 20:47:08 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 009E111E814D for <ipsec@ietf.org>; Tue, 20 Aug 2013 20:47:06 -0700 (PDT)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7L3l5vU030863 for <ipsec@ietf.org>; Wed, 21 Aug 2013 06:47:05 +0300
X-CheckPoint: {52143839-C-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Wed, 21 Aug 2013 06:47:04 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: "<ipsec@ietf.org> WG" <ipsec@ietf.org>
Thread-Topic: New Version Notification for draft-sathyanarayan-ipsecme-advpn-01.txt
Thread-Index: AQHOnfuOz+iAPNkSB0iAYHJ+nijqcQ==
Date: Wed, 21 Aug 2013 03:47:04 +0000
Message-ID: <A0B7531E-CDBC-486F-A893-4A4F75AA13F6@checkpoint.com>
References: <CE394AE7.1A7C67%praveenys@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.218]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
x-cpdlp: 11fedcd0c57f4c7f0e0aec4ebfa77bcede0b6902ed
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <6104710823AFF4448CB789B4DCA51154@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [IPsec] Fwd: New Version Notification for draft-sathyanarayan-ipsecme-advpn-01.txt
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, 21 Aug 2013 03:47:13 -0000

Hi IPsec-WG,

Based on the review comments from various working group members, we have
made a revision to our original proposal for ADVPN protocol. In this
revision, we have tried to address most review comments. More review
comments will be addressed in future revisions. Please take a look at it
and provide us your valuable comment.

Changes done in this revision:
 * Introduced new exchange type called SHORTCUT exchange, instead of SHORTC=
UT Notify payload.
 * Added few new notification payloads, which carries shortcut information =
and shortcut status.
 * Added new ID payload called Peer Address Identification Payload. This co=
mbines IPv4, IPv6 and FQDN Shortcut types into one.
 * Instead of using vendor-id to advertise ADVPN protocol, this draft propo=
ses to use ADVPN_SUPPORTED notification payload. This notification payload =
also carries additional information like, capabilities supported by endpoin=
ts.
 * Now shortcut information carries shortcut peer's port number, as well. T=
his improves NAT scenarios supported by this draft.

Thanks,
Praveen

On 8/20/13 4:18 PM, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
wrote:


A new version of I-D, draft-sathyanarayan-ipsecme-advpn-01.txt
has been successfully submitted by Praveen Sathyanarayan and posted to the
IETF repository.

Filename:	 draft-sathyanarayan-ipsecme-advpn
Revision:	 01
Title:		 Auto Discovery VPN Protocol
Creation date:	 2013-08-20
Group:		 Individual Submission
Number of pages: 40
URL:             http://www.ietf.org/internet-drafts/draft-sathyanarayan-ip=
secme-advpn-01.txt
Status:          http://datatracker.ietf.org/doc/draft-sathyanarayan-ipsecm=
e-advpn
Htmlized:        http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-adv=
pn-01
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-sathyanarayan-ips=
ecme-advpn-01

Abstract:
  This document defines a protocol for dynamically establishing and tearing
  down IPsec tunnels as needed without requiring non-scalable configuration=
.




Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

From yaronf.ietf@gmail.com  Tue Aug 20 22:54:12 2013
Return-Path: <yaronf.ietf@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 8052F11E8370 for <ipsec@ietfa.amsl.com>; Tue, 20 Aug 2013 22:54:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qx1JbZokscb for <ipsec@ietfa.amsl.com>; Tue, 20 Aug 2013 22:54:12 -0700 (PDT)
Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id B3A1111E81A1 for <ipsec@ietf.org>; Tue, 20 Aug 2013 22:54:11 -0700 (PDT)
Received: by mail-wg0-f49.google.com with SMTP id y10so1137769wgg.16 for <ipsec@ietf.org>; Tue, 20 Aug 2013 22:54:09 -0700 (PDT)
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=WjLznJ5LAWMLrEBkBJ6z3VaIoj+pMp5Dqrzpx3A836M=; b=MezfgnXFPY7f87Day1n/xjzTXePHM0WaMzZOrbZZXR7sAjdGvKtvtFL3CDLqPP0xMz IuLFePcxYf1Ji1oXFiLOF4dSQL518zpwKMyToprm7ay7uoDUEhO9XRrPDz8JsyvH7Pes g0JFkqfZmFUkxWaBvUQ+jsX1HTcCjnRpdCO6fdXwDprZIHrB1SayqqfDhzJAeH0uKg9S kYxoKXprz7pYQOTbat+db7E0A8IGkLCkdn/66t13SfC3hh7A/sqdnQcXoIX1bhqlM3XV +sPXcnu/oxdmqrwwTkjsqe4+yfLF97+XMr6rNK0tFnB5IK3wBq8JwOPuRkylJWLDRuZS +1GA==
X-Received: by 10.180.86.226 with SMTP id s2mr4061519wiz.7.1377064449640; Tue, 20 Aug 2013 22:54:09 -0700 (PDT)
Received: from [192.168.43.242] ([46.19.80.6]) by mx.google.com with ESMTPSA id li9sm7196555wic.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Aug 2013 22:54:09 -0700 (PDT)
Message-ID: <52144CAA.5020206@gmail.com>
Date: Wed, 21 Aug 2013 08:14:18 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>
References: <CE394AE7.1A7C67%praveenys@juniper.net> <A0B7531E-CDBC-486F-A893-4A4F75AA13F6@checkpoint.com>
In-Reply-To: <A0B7531E-CDBC-486F-A893-4A4F75AA13F6@checkpoint.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "<ipsec@ietf.org> WG" <ipsec@ietf.org>
Subject: Re: [IPsec] Fwd: New Version Notification for draft-sathyanarayan-ipsecme-advpn-01.txt
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, 21 Aug 2013 05:54:12 -0000

Thank you for the new version. Two quick comments:

- I'm not very happy with the standard payload referencing an opaque VID 
payload.

- In Sec. 3.8, why are the TSx payloads "bare", with their payload 
headers stripped out?

Thanks,
	Yaron

On 2013-08-21 06:47, Yoav Nir wrote:
>
> Hi IPsec-WG,
>
> Based on the review comments from various working group members, we have
> made a revision to our original proposal for ADVPN protocol. In this
> revision, we have tried to address most review comments. More review
> comments will be addressed in future revisions. Please take a look at it
> and provide us your valuable comment.
>
> Changes done in this revision:
>   * Introduced new exchange type called SHORTCUT exchange, instead of SHORTCUT Notify payload.
>   * Added few new notification payloads, which carries shortcut information and shortcut status.
>   * Added new ID payload called Peer Address Identification Payload. This combines IPv4, IPv6 and FQDN Shortcut types into one.
>   * Instead of using vendor-id to advertise ADVPN protocol, this draft proposes to use ADVPN_SUPPORTED notification payload. This notification payload also carries additional information like, capabilities supported by endpoints.
>   * Now shortcut information carries shortcut peer's port number, as well. This improves NAT scenarios supported by this draft.
>
> Thanks,
> Praveen
>
> On 8/20/13 4:18 PM, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
> wrote:
>
>
> A new version of I-D, draft-sathyanarayan-ipsecme-advpn-01.txt
> has been successfully submitted by Praveen Sathyanarayan and posted to the
> IETF repository.
>
> Filename:	 draft-sathyanarayan-ipsecme-advpn
> Revision:	 01
> Title:		 Auto Discovery VPN Protocol
> Creation date:	 2013-08-20
> Group:		 Individual Submission
> Number of pages: 40
> URL:             http://www.ietf.org/internet-drafts/draft-sathyanarayan-ipsecme-advpn-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-sathyanarayan-ipsecme-advpn
> Htmlized:        http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-01
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-sathyanarayan-ipsecme-advpn-01
>
> Abstract:
>    This document defines a protocol for dynamically establishing and tearing
>    down IPsec tunnels as needed without requiring non-scalable configuration.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>

From ynir@checkpoint.com  Tue Aug 20 23:32:56 2013
Return-Path: <ynir@checkpoint.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 C420811E81AA for <ipsec@ietfa.amsl.com>; Tue, 20 Aug 2013 23:32:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.708
X-Spam-Level: 
X-Spam-Status: No, score=-10.708 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RV4eCqGjS8Qo for <ipsec@ietfa.amsl.com>; Tue, 20 Aug 2013 23:32:52 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9F27311E8165 for <ipsec@ietf.org>; Tue, 20 Aug 2013 23:32:51 -0700 (PDT)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7L6WmUc029905; Wed, 21 Aug 2013 09:32:48 +0300
X-CheckPoint: {52145F10-6-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Wed, 21 Aug 2013 09:32:48 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Thread-Topic: [IPsec] New Version Notification for draft-sathyanarayan-ipsecme-advpn-01.txt
Thread-Index: AQHOnjhAlMg3PwskjECpv99dk718Bg==
Date: Wed, 21 Aug 2013 06:32:48 +0000
Message-ID: <27AE3251-89CA-4CA5-A1CE-393579C48162@checkpoint.com>
References: <CE394AE7.1A7C67%praveenys@juniper.net> <A0B7531E-CDBC-486F-A893-4A4F75AA13F6@checkpoint.com> <52144CAA.5020206@gmail.com>
In-Reply-To: <52144CAA.5020206@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.127]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
x-cpdlp: 11c9245ab2e951015932e3446b20fd85565de43e51
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <7E5B139B57623E4991C0E88888491145@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<ipsec@ietf.org> WG" <ipsec@ietf.org>
Subject: Re: [IPsec] New Version Notification for draft-sathyanarayan-ipsecme-advpn-01.txt
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, 21 Aug 2013 06:32:56 -0000

On Aug 21, 2013, at 8:14 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

> Thank you for the new version. Two quick comments:
>=20
> - I'm not very happy with the standard payload referencing an opaque VID =
payload.

If all of the authorization is based on IP addresses and ports, it can be e=
xpressed in traffic selectors, and we don't really need to convey any "real=
" identity. However, if some of the policy is more complicated (such as nex=
t generation firewalls like to do - John is allowed to transfer files over =
Skype, but Jack is only allowed voice conversations), then passing the iden=
tity to the shortcut partner is important. Unfortunately, there is no vendo=
r-neutral way to pass user records among gateways.

> - In Sec. 3.8, why are the TSx payloads "bare", with their payload header=
s stripped out?

Cut-and-paste error from -00. Will fix in -02.

>=20
> Thanks,
> 	Yaron
>=20
> On 2013-08-21 06:47, Yoav Nir wrote:
>>=20
>> Hi IPsec-WG,
>>=20
>> Based on the review comments from various working group members, we have
>> made a revision to our original proposal for ADVPN protocol. In this
>> revision, we have tried to address most review comments. More review
>> comments will be addressed in future revisions. Please take a look at it
>> and provide us your valuable comment.
>>=20
>> Changes done in this revision:
>>  * Introduced new exchange type called SHORTCUT exchange, instead of SHO=
RTCUT Notify payload.
>>  * Added few new notification payloads, which carries shortcut informati=
on and shortcut status.
>>  * Added new ID payload called Peer Address Identification Payload. This=
 combines IPv4, IPv6 and FQDN Shortcut types into one.
>>  * Instead of using vendor-id to advertise ADVPN protocol, this draft pr=
oposes to use ADVPN_SUPPORTED notification payload. This notification paylo=
ad also carries additional information like, capabilities supported by endp=
oints.
>>  * Now shortcut information carries shortcut peer's port number, as well=
. This improves NAT scenarios supported by this draft.
>>=20
>> Thanks,
>> Praveen
>>=20
>> On 8/20/13 4:18 PM, "internet-drafts@ietf.org" <internet-drafts@ietf.org=
>
>> wrote:
>>=20
>>=20
>> A new version of I-D, draft-sathyanarayan-ipsecme-advpn-01.txt
>> has been successfully submitted by Praveen Sathyanarayan and posted to t=
he
>> IETF repository.
>>=20
>> Filename:	 draft-sathyanarayan-ipsecme-advpn
>> Revision:	 01
>> Title:		 Auto Discovery VPN Protocol
>> Creation date:	 2013-08-20
>> Group:		 Individual Submission
>> Number of pages: 40
>> URL:             http://www.ietf.org/internet-drafts/draft-sathyanarayan=
-ipsecme-advpn-01.txt
>> Status:          http://datatracker.ietf.org/doc/draft-sathyanarayan-ips=
ecme-advpn
>> Htmlized:        http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-=
advpn-01
>> Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-sathyanarayan-=
ipsecme-advpn-01
>>=20
>> Abstract:
>>   This document defines a protocol for dynamically establishing and tear=
ing
>>   down IPsec tunnels as needed without requiring non-scalable configurat=
ion.
>>=20
>>=20
>>=20
>>=20
>> Please note that it may take a couple of minutes from the time of submis=
sion
>> until the htmlized version and diff are available at tools.ietf.org.
>>=20
>> The IETF Secretariat
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>=20
>=20
> Email secured by Check Point


From soundariya.lakshmi.v.m@ericsson.com  Wed Aug 21 04:38:08 2013
Return-Path: <soundariya.lakshmi.v.m@ericsson.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 308D411E8203 for <ipsec@ietfa.amsl.com>; Wed, 21 Aug 2013 04:38:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yUWA1aSTPUx for <ipsec@ietfa.amsl.com>; Wed, 21 Aug 2013 04:38:02 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AA4DA11E8200 for <ipsec@ietf.org>; Wed, 21 Aug 2013 04:38:01 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-0a-5214a697e944
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 47.6F.03802.796A4125; Wed, 21 Aug 2013 13:38:00 +0200 (CEST)
Received: from 65XG8R1.egi.ericsson.com (153.88.183.149) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.2.328.9; Wed, 21 Aug 2013 13:37:59 +0200
Message-ID: <5214A696.6060101@ericsson.com>
Date: Wed, 21 Aug 2013 17:07:58 +0530
From: Soundariya M <soundariya.lakshmi.v.m@ericsson.com>
Organization: Ericsson India Global Services Pvt. Ltd
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: <ipsec@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLJMWRmVeSWpSXmKPExsUyM+Jvje6MZSJBBucmsFns3/KCzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGXdnrGUsOMNUMXn7McYGxr+MXYwcHBICJhIP1+t0MXICmWIS F+6tZ+ti5OIQEjjMKPH87VsmCGcLo8SbdUeZQap4BbQlOjd9ZQexWQRUJTYvfAZmswlYSBxs 28UIYgsJ6Euc2vEaLM4vYCrxsHcWK8gyUYEwiek72SHGCEqcnPmEBcQWERCReHbiOCuILSwg JfH79jqwOLOArcSFOdehbHmJ7W/nMEOMN5D4ubmXeQKjwCwko2YhaZmFpGUBI/MqRvbcxMyc 9HKjTYzAIDu45bfqDsY750QOMUpzsCiJ827WOxMoJJCeWJKanZpakFoUX1Sak1p8iJGJg1Oq gXGp//mDbB5qlgFr+/csNPfLdzl96uYf5eLsle9XnFQSCj7CsWwzt9ldtplbl7jGLro1b+Yh 8bcH/OfuYVRU6trSYnA4b8GT4sSueOvdnEpzH9/LW7NNJmfuw18TLWftPPjvsaK7p0THr6n/ sxbd1l28+Orz9T9O/v5zPy3uiMZZ+5K8vQ8/xdrcU2Ipzkg01GIuKk4EAHIUn8QAAgAA
X-Mailman-Approved-At: Wed, 21 Aug 2013 09:24:46 -0700
Subject: [IPsec] CHILD_SA Deletion
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: soundariya.lakshmi.v.m@ericsson.com
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, 21 Aug 2013 11:40:11 -0000

Hi,
     I have an specific query in CHILD_SA delete message during 
rekeying. What should be the SPI value while deleting the child_sa 
(local SPI or receiver's SPI?) ?
     If it is local SPI, how the peer will fetch its corresponding 
CHILD_SA to delete? Can someone help me to get clarity on this?


Thanks
Soundariya

From ynir@checkpoint.com  Thu Aug 22 01:33:12 2013
Return-Path: <ynir@checkpoint.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 3DFF521F9D4F for <ipsec@ietfa.amsl.com>; Thu, 22 Aug 2013 01:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5yrCm4XgECA for <ipsec@ietfa.amsl.com>; Thu, 22 Aug 2013 01:33:07 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id BA1F821F9D50 for <ipsec@ietf.org>; Thu, 22 Aug 2013 01:33:06 -0700 (PDT)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7M8X4pw004379 for <ipsec@ietf.org>; Thu, 22 Aug 2013 11:33:04 +0300
X-CheckPoint: {5215CCC0-36-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Thu, 22 Aug 2013 11:33:04 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: New Version Notification for draft-nir-ipsecme-cafr-01.txt
Thread-Index: AQHOnxFBJ+JfYG/LRk+xQBfnlbaIxZmg5RmA
Date: Thu, 22 Aug 2013 08:33:04 +0000
Message-ID: <4613980CFC78314ABFD7F85CC30277211E142723@IL-EX10.ad.checkpoint.com>
References: <20130822082557.14729.56675.idtracker@ietfa.amsl.com>
In-Reply-To: <20130822082557.14729.56675.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [91.90.139.27]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
x-cpdlp: 11356645e6472cdd679515e33fa2ecfe24f61715f4
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: [IPsec] FW: New Version Notification for draft-nir-ipsecme-cafr-01.txt
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: Thu, 22 Aug 2013 08:33:12 -0000

SGkNCg0KSSd2ZSBzdWJtaXR0ZWQgdmVyc2lvbiAtMDEgb2YgbXkgZHJhZnQuIEl0IGluY29ycG9y
YXRlcyBWYWxlcnkncyBzdWdnZXN0aW9uIHRvIG1vdmUgdGhlICJhZG9wdGlvbiIgdG8gYW4gZXhj
aGFuZ2UgcHJvdGVjdGVkIGJ5IHRoZSBvbGQgSUtFIFNBIHJhdGhlciB0aGFuIHRoZSBJS0VfQVVU
SCBleGNoYW5nZSB0aGF0IGNyZWF0ZXMgdGhlIG5ldyBJS0UgU0EuIFNpbmNlIGNoaWxkIFNBcyBh
cmUgInB1c2hlZCIgaW5zdGVhZCBvZiAicHVsbGVkIiwgSSBjaGFuZ2VkIHRoZSBuYW1lIGZyb20g
ImFkb3B0aW5nIiB0byAiaGFuZGluZyBvdmVyIiAoYmVjYXVzZSAiZ2l2aW5nIHVwIiBzZWVtZWQg
dG8gYmUgY2FycnlpbmcgdGhpcyB0b28gZmFyIDotKSApDQoNClRoaXMgY2hhbmdlIGFsc28gc2lt
cGxpZmllcyB0aGUgcHJvdG9jb2wsIGFuZCBJTU8gcmVtb3ZlcyB0aGUgbmVlZCB0byBjcnlwdG9n
cmFwaGljYWxseSBiaW5kIHRoZSB0cmFuc2Zlci4NCg0KWW9hdg0KDQotLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJu
ZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjIsIDIwMTMgMTE6
MjYgQU0NClRvOiBZb2F2IE5pcg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv
ciBkcmFmdC1uaXItaXBzZWNtZS1jYWZyLTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E
LCBkcmFmdC1uaXItaXBzZWNtZS1jYWZyLTAxLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi
bWl0dGVkIGJ5IFlvYXYgTmlyIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0K
RmlsZW5hbWU6CSBkcmFmdC1uaXItaXBzZWNtZS1jYWZyDQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJ
CSBIYW5kaW5nIE92ZXIgQ2hpbGQgU0FzIEZvbGxvd2luZyBSZS1BdXRoZW50aWNhdGlvbiBpbiBJ
S0V2Mg0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDgtMjINCkdyb3VwOgkJIEluZGl2aWR1YWwgU3Vi
bWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA3DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cu
aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW5pci1pcHNlY21lLWNhZnItMDEudHh0DQpT
dGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbmly
LWlwc2VjbWUtY2Fmcg0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1uaXItaXBzZWNtZS1jYWZyLTAxDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cu
aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW5pci1pcHNlY21lLWNhZnItMDENCg0KQWJzdHJh
Y3Q6DQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhbiBleHRlbnNpb24gdG8gdGhlIElLRXYy
IHByb3RvY29sIHdoZXJlYnkNCiAgIENoaWxkIFNBcyBhcmUgbW92ZWQgdG8gdGhlIG5ldyBJS0Ug
U0EgZm9sbG93aW5nIHJlLWF1dGhlbnRpY2F0aW9uLg0KICAgVGhpcyBhbGxvd3MgZm9yIGEgc21v
b3RoZXIgdHJhbnNpdGlvbiB3aXRoIG5vIGxvc3Mgb2YgY29ubmVjdGl2aXR5Lg0KDQo=

From internet-drafts@ietf.org  Fri Aug 23 05:59:38 2013
Return-Path: <internet-drafts@ietf.org>
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 D513211E81B7; Fri, 23 Aug 2013 05:59:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.584
X-Spam-Level: 
X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHm0U7t2hNmi; Fri, 23 Aug 2013 05:59:38 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DE111E80FF; Fri, 23 Aug 2013 05:59:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.70.p1
Message-ID: <20130823125938.2241.70162.idtracker@ietfa.amsl.com>
Date: Fri, 23 Aug 2013 05:59:38 -0700
Cc: ipsec@ietf.org
Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-01.txt
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: Fri, 23 Aug 2013 12:59:39 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the IP Security Maintenance and Extensions Wo=
rking Group of the IETF.

	Title           : IKEv2 Fragmentation
	Author(s)       : Valery Smyslov
	Filename        : draft-ietf-ipsecme-ikev2-fragmentation-01.txt
	Pages           : 19
	Date            : 2013-08-23

Abstract:
   This document describes the way to avoid IP fragmentation of large
   IKEv2 messages.  This allows IKEv2 messages to traverse network
   devices that don't allow IP fragments to pass through.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-ikev2-fragmentation-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From svanru@gmail.com  Fri Aug 23 06:36:07 2013
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 CAD4311E80DC for <ipsec@ietfa.amsl.com>; Fri, 23 Aug 2013 06:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXUiZPM5R3Sh for <ipsec@ietfa.amsl.com>; Fri, 23 Aug 2013 06:36:07 -0700 (PDT)
Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id CE20B11E80D2 for <ipsec@ietf.org>; Fri, 23 Aug 2013 06:36:06 -0700 (PDT)
Received: by mail-bk0-f45.google.com with SMTP id mx11so232958bkb.18 for <ipsec@ietf.org>; Fri, 23 Aug 2013 06:36:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=5B9YmI94FrBlnjG2RGqBFF8pO4uGv6Awy7ElEQcBdrQ=; b=tJEj0MncXnCUoUpptYe0LKHxeqKj+eUmm3KUF8ZP7vvoPff6CDZc0pUyavuAzaAvWp Rw1tn1RSDG5xlsW8IuFANC3+ROjJeDUb1GxxCB7w6KHmFPT2vRf5nk44E2eWO+FA3xcy 2nWIaTvCe7xdpsM5i7MPRHLigofxi4QogBcnOfx+DkZ5GuZhkMk8Nn+lUsshXBVuCJGq 64oPnIYAFlQm0+mlYLnwCzuzeQ2XVA0/0VaaClBuExr1JCBiiv3XoikjX8Z9E39QOT+S EQ/H4HSWb35frzq+SEc6MbTYg1dJVNkxsx52In5s6g/TpYTsBv8SoQabOvCJNU+3kwDZ Ma2g==
X-Received: by 10.205.5.6 with SMTP id oe6mr1991506bkb.36.1377264965915; Fri, 23 Aug 2013 06:36:05 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id zl3sm4233805bkb.4.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 23 Aug 2013 06:36:05 -0700 (PDT)
Message-ID: <57EAE4A995FE40FAA964CE20ADA8FB18@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: <ipsec@ietf.org>
References: <20130823125938.2241.70162.idtracker@ietfa.amsl.com>
Date: Fri, 23 Aug 2013 17:35:50 +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
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-01.txt
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: Fri, 23 Aug 2013 13:36:07 -0000

Hi all,

I've just posted new version of IKEv2 Fragmentation draft.
Comments and reviews are appreciated.

Differences ftom -00 version:
1. As Yaron suggested Transport Considerations section is added and
    cryptographic processing of Encrypted Fragment Payload is clarified.
2. Based on comments from WG members Design Rationale Appendix is added.
3. Some sections are rewritten to improve (I hope) document clarity.

I am still not convinced to include additional field to 
IKE_FRAGMENTATION_SUPPORTED
notification, indicating peer's impression of PMTU, as Yaron suggested.

The reason is that some people consider IKE Fragmentation to be complex.
In this situation I see my goal not to do it more complex. Currently
ability to do PMTU discovery in the protocol is completely optional, all key 
words
that are concerned with this feature are "MAY". I suspect, that most 
implementations
won't do it and will just use fixed recommended values for fragments size.
Adding these fields is just an optimization and it will work only
for that minority of implementations, that will do PMTU discovery.
And even for them in most use cases it won't help much.
So, my opinion - it is not justified. And I still haven't see any
supporting comment from the WG. Yaron?

Probably we should get rid of (even completely optional) PMTU discovery at 
all,
if it encouraged people to implement the protocol.

Regards,
Valery Smyslov.


> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the IP Security Maintenance and Extensions 
> Working Group of the IETF.
>
> Title           : IKEv2 Fragmentation
> Author(s)       : Valery Smyslov
> Filename        : draft-ietf-ipsecme-ikev2-fragmentation-01.txt
> Pages           : 19
> Date            : 2013-08-23
>
> Abstract:
>   This document describes the way to avoid IP fragmentation of large
>   IKEv2 messages.  This allows IKEv2 messages to traverse network
>   devices that don't allow IP fragments to pass through.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-01
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-fragmentation-01
>
>
> Please note that it may take a couple of minutes from the time of 
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec 


From yaronf.ietf@gmail.com  Fri Aug 23 06:59:24 2013
Return-Path: <yaronf.ietf@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 B3ED411E82F7 for <ipsec@ietfa.amsl.com>; Fri, 23 Aug 2013 06:59:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.478
X-Spam-Level: 
X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBH4P55tQZ1M for <ipsec@ietfa.amsl.com>; Fri, 23 Aug 2013 06:59:24 -0700 (PDT)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7038311E82FA for <ipsec@ietf.org>; Fri, 23 Aug 2013 06:59:22 -0700 (PDT)
Received: by mail-wi0-f179.google.com with SMTP id hr7so604929wib.6 for <ipsec@ietf.org>; Fri, 23 Aug 2013 06:59:21 -0700 (PDT)
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=4lYO3Cf+VK0LJy0pshJCWUyvRHgcPDIXru8dV0RyR2w=; b=UcWcfaRq/cS1kKgxmm537HWP7IPOlRzDo8uFdByEX8TMsJbHTJ5c5xwoZQxf4iz5b7 qB4wr5xzUY6FdfEmL9m8v7aIOpT4cDUwYjNQt8CtgBW6WW8MNRknoEeFJTa+OK94FeCF V44WcVz9vtW6XhWrJOiauT41FqyMatc24xsOKIJf6C65q20Rx7SN/lmnmfSH6SAjJxGX GN4MkMIhf5jo699PqpO9YuaPgVkFc7pNanwUraQ/1NOXUuDpRPPvZbfmvPTSDKAOfBxf 5tIXasedGyebjFeXfXjAbvfozCg9e4PIEKyyFXXMroQw24Gds27eqDqPnzTic3Yk3tpP Bq2w==
X-Received: by 10.180.187.41 with SMTP id fp9mr2295727wic.33.1377266361139; Fri, 23 Aug 2013 06:59:21 -0700 (PDT)
Received: from [10.0.0.6] (bzq-79-181-211-116.red.bezeqint.net. [79.181.211.116]) by mx.google.com with ESMTPSA id jc18sm4184028wic.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Aug 2013 06:59:20 -0700 (PDT)
Message-ID: <52176AB6.7070005@gmail.com>
Date: Fri, 23 Aug 2013 16:59:18 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: Valery Smyslov <svanru@gmail.com>
References: <20130823125938.2241.70162.idtracker@ietfa.amsl.com> <57EAE4A995FE40FAA964CE20ADA8FB18@buildpc>
In-Reply-To: <57EAE4A995FE40FAA964CE20ADA8FB18@buildpc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ipsec@ietf.org
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-01.txt
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: Fri, 23 Aug 2013 13:59:24 -0000

Hi Valery,

Thank you for submitting the new version.

I am fine if you choose not to include the fragment size hint in the 
notification, unless there are opposing views on the list.

Regarding the new Transport Considerations section: please add a 
sentence that mentions that there is only an ack for the last fragment 
of each message, so that people who are not IKE experts can understand.

Also, we should say somewhere (maybe in this section) that each receiver 
must establish a timeout for the reassembly buffer, and silently discard 
any collected fragments if the whole message could not be reassembled by 
that time.

Thanks,
	Yaron

On 2013-08-23 16:35, Valery Smyslov wrote:
> Hi all,
>
> I've just posted new version of IKEv2 Fragmentation draft.
> Comments and reviews are appreciated.
>
> Differences ftom -00 version:
> 1. As Yaron suggested Transport Considerations section is added and
>     cryptographic processing of Encrypted Fragment Payload is clarified.
> 2. Based on comments from WG members Design Rationale Appendix is added.
> 3. Some sections are rewritten to improve (I hope) document clarity.
>
> I am still not convinced to include additional field to
> IKE_FRAGMENTATION_SUPPORTED
> notification, indicating peer's impression of PMTU, as Yaron suggested.
>
> The reason is that some people consider IKE Fragmentation to be complex.
> In this situation I see my goal not to do it more complex. Currently
> ability to do PMTU discovery in the protocol is completely optional, all
> key words
> that are concerned with this feature are "MAY". I suspect, that most
> implementations
> won't do it and will just use fixed recommended values for fragments size.
> Adding these fields is just an optimization and it will work only
> for that minority of implementations, that will do PMTU discovery.
> And even for them in most use cases it won't help much.
> So, my opinion - it is not justified. And I still haven't see any
> supporting comment from the WG. Yaron?
>
> Probably we should get rid of (even completely optional) PMTU discovery
> at all,
> if it encouraged people to implement the protocol.
>
> Regards,
> Valery Smyslov.
>
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the IP Security Maintenance and
>> Extensions Working Group of the IETF.
>>
>> Title           : IKEv2 Fragmentation
>> Author(s)       : Valery Smyslov
>> Filename        : draft-ietf-ipsecme-ikev2-fragmentation-01.txt
>> Pages           : 19
>> Date            : 2013-08-23
>>
>> Abstract:
>>   This document describes the way to avoid IP fragmentation of large
>>   IKEv2 messages.  This allows IKEv2 messages to traverse network
>>   devices that don't allow IP fragments to pass through.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-01
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-fragmentation-01
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

From svanru@gmail.com  Fri Aug 23 07:05:06 2013
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 31D5011E81BD for <ipsec@ietfa.amsl.com>; Fri, 23 Aug 2013 07:05:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrcQkOintf9D for <ipsec@ietfa.amsl.com>; Fri, 23 Aug 2013 07:05:05 -0700 (PDT)
Received: from mail-bk0-x235.google.com (mail-bk0-x235.google.com [IPv6:2a00:1450:4008:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5FD11E80DE for <ipsec@ietf.org>; Fri, 23 Aug 2013 07:04:50 -0700 (PDT)
Received: by mail-bk0-f53.google.com with SMTP id d7so246037bkh.40 for <ipsec@ietf.org>; Fri, 23 Aug 2013 07:04:49 -0700 (PDT)
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=4t91q6cGDrq2cG3C+8Z1AAqfM+j8NInClbzZ/Y3i+Uk=; b=OVYwZhQ2cegDdRsB7AfO/rqgY8h2PXT/Yiyxwajqk3usMFdvxjI/FowWbzLdPB6Nbi 236kL359TlS5CX86pSBzrpWY7MqRrkcg48j5clfb/OxcyiQ5TWhBplNJnZs44vEiaqGO OzPRjowQIqb7SHF9YNPp+Co50prQfVqBoCEqNYNO0P9aZ5eBsPc7U9p2wNmMPSGUq5+a JNx4bE7O0BMhj0ea1bYq8cvz67b2nEGK3uGd7dzcKAvjFBuoJ30fdT7xqV89VeHjFB8i z3xYGkUTzyc5LOzRF9hG3LTtak36vASWvehK2LZAJgdtGppy7oqx73gQNZN1rrHYte8R m9Jg==
X-Received: by 10.205.64.68 with SMTP id xh4mr3360bkb.183.1377266689462; Fri, 23 Aug 2013 07:04:49 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id ku9sm3636bkb.1.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 23 Aug 2013 07:04:48 -0700 (PDT)
Message-ID: <45A3B9E66C4842159D0220343E14F9A9@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Yaron Sheffer" <yaronf.ietf@gmail.com>
References: <20130823125938.2241.70162.idtracker@ietfa.amsl.com> <57EAE4A995FE40FAA964CE20ADA8FB18@buildpc> <52176AB6.7070005@gmail.com>
Date: Fri, 23 Aug 2013 18:04:37 +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
Cc: ipsec@ietf.org
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-01.txt
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: Fri, 23 Aug 2013 14:05:06 -0000

> Hi Valery,

Hi Yaron,

> Thank you for submitting the new version.
>
> I am fine if you choose not to include the fragment size hint in the 
> notification, unless there are opposing views on the list.
>
> Regarding the new Transport Considerations section: please add a sentence 
> that mentions that there is only an ack for the last fragment of each 
> message, so that people who are not IKE experts can understand.

OK.

> Also, we should say somewhere (maybe in this section) that each receiver 
> must establish a timeout for the reassembly buffer, and silently discard 
> any collected fragments if the whole message could not be reassembled by 
> that time.

OK.

Regards,
Valery.

> Thanks,
> Yaron
>
> On 2013-08-23 16:35, Valery Smyslov wrote:
>> Hi all,
>>
>> I've just posted new version of IKEv2 Fragmentation draft.
>> Comments and reviews are appreciated.
>>
>> Differences ftom -00 version:
>> 1. As Yaron suggested Transport Considerations section is added and
>>     cryptographic processing of Encrypted Fragment Payload is clarified.
>> 2. Based on comments from WG members Design Rationale Appendix is added.
>> 3. Some sections are rewritten to improve (I hope) document clarity.
>>
>> I am still not convinced to include additional field to
>> IKE_FRAGMENTATION_SUPPORTED
>> notification, indicating peer's impression of PMTU, as Yaron suggested.
>>
>> The reason is that some people consider IKE Fragmentation to be complex.
>> In this situation I see my goal not to do it more complex. Currently
>> ability to do PMTU discovery in the protocol is completely optional, all
>> key words
>> that are concerned with this feature are "MAY". I suspect, that most
>> implementations
>> won't do it and will just use fixed recommended values for fragments 
>> size.
>> Adding these fields is just an optimization and it will work only
>> for that minority of implementations, that will do PMTU discovery.
>> And even for them in most use cases it won't help much.
>> So, my opinion - it is not justified. And I still haven't see any
>> supporting comment from the WG. Yaron?
>>
>> Probably we should get rid of (even completely optional) PMTU discovery
>> at all,
>> if it encouraged people to implement the protocol.
>>
>> Regards,
>> Valery Smyslov.
>>
>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the IP Security Maintenance and
>>> Extensions Working Group of the IETF.
>>>
>>> Title           : IKEv2 Fragmentation
>>> Author(s)       : Valery Smyslov
>>> Filename        : draft-ietf-ipsecme-ikev2-fragmentation-01.txt
>>> Pages           : 19
>>> Date            : 2013-08-23
>>>
>>> Abstract:
>>>   This document describes the way to avoid IP fragmentation of large
>>>   IKEv2 messages.  This allows IKEv2 messages to traverse network
>>>   devices that don't allow IP fragments to pass through.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-01
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-fragmentation-01
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> IPsec mailing list
>>> IPsec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec 


From yaronf.ietf@gmail.com  Sat Aug 24 23:46:02 2013
Return-Path: <yaronf.ietf@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 3DD3811E821D for <ipsec@ietfa.amsl.com>; Sat, 24 Aug 2013 23:45:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ua18UPB7V9-J for <ipsec@ietfa.amsl.com>; Sat, 24 Aug 2013 23:45:54 -0700 (PDT)
Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5362C11E821C for <ipsec@ietf.org>; Sat, 24 Aug 2013 23:45:44 -0700 (PDT)
Received: by mail-ea0-f178.google.com with SMTP id a15so1009116eae.37 for <ipsec@ietf.org>; Sat, 24 Aug 2013 23:45:43 -0700 (PDT)
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:subject :content-type:content-transfer-encoding; bh=WhP2eaygHWLejIgnRjVHx99ipj6rEbXV8MCdNpYOqIA=; b=hycXLREadFg0HvmsnLD4tzBlbNPhll+0u8WKVc0gzEUCj3ac80/yFn30OjfPgIK6wH t4HwAL63EnHYpI9PHhXDnRkCcGxH8qwgYSlTLH/HfgRkqoyC0Fh+s4zHI6EoL8+QEWCL Tr65j+8JqggYpsqAoSBogoDO8Wx1PkjiHSRgLl97Qhb3x/Elyk/oGeZUvWHNbYVH+BLl D4o5MU2HaoodFfyR/merndo3oaU5Xjk7YcA59ae0JCZsKT7CdNRGXa9GqKyZrRnEShPC /rtKszmrZ/uGbwDvB0FKfb0pK2cCkPiirBDqER4k5/BieohAjF8GAAsY4XXgP1ESUvxi fvtA==
X-Received: by 10.14.198.65 with SMTP id u41mr640097een.59.1377413143483; Sat, 24 Aug 2013 23:45:43 -0700 (PDT)
Received: from [10.0.0.7] ([109.64.167.171]) by mx.google.com with ESMTPSA id a6sm11930175eei.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Aug 2013 23:45:43 -0700 (PDT)
Message-ID: <5219A814.2070603@gmail.com>
Date: Sun, 25 Aug 2013 09:45:40 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: IPsecme WG <ipsec@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [IPsec] CAFR -01 comments
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: Sun, 25 Aug 2013 06:46:03 -0000

Hi Yoav,

I started by reading -01, then went back to -00. And I think the two can 
be merged to create a better solution.

Including the notification as soon as the peers know they want a 
handover is cleaner. So IKE_AUTH (of the new SA) is better than DELETE, 
and in fact IKE_SA_INIT would be even more useful because then you can 
define that all such IKE SAs are implicitly childless, and avoid the 
need for the RFC 6023 notification.

CAFR -01 says a peer is allowed to hand over the Child SAs if it 
successfully authenticates to the other peer and has the same 
authenticated identity. Seems to me this is symmetric, i.e. it doesn't 
matter if the exchange is run over the "old" or the "new" IKE SA. And so 
this could apply just as well to -00, and the POP stuff is not needed.

I'm not sure about the race discussion in -00, because it only applies 
in failure cases. Can't an attacker "swallow" a few DELETE messages or 
their responses and cause a similar database mismatch?

Also note that the notification syntax is in conflict with both RFC 5996 
and RFC 4306. RFC 5996 removes the option of Protocol ID=1, while RFC 
4306 assumes that we are talking about the *current* IKE SA, and so 
mandates that the SPI field should be empty in this case. Practically 
speaking, we will have to fix 5996 before this can document move 
forward. Luckily we're doing just that with Tero's bis draft.

Thanks,
     Yaron

From ynir@checkpoint.com  Sun Aug 25 00:53:41 2013
Return-Path: <ynir@checkpoint.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 047C711E8230 for <ipsec@ietfa.amsl.com>; Sun, 25 Aug 2013 00:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.692
X-Spam-Level: 
X-Spam-Status: No, score=-10.692 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxZHkZuE-z2n for <ipsec@ietfa.amsl.com>; Sun, 25 Aug 2013 00:53:35 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4E24321F9E28 for <ipsec@ietf.org>; Sun, 25 Aug 2013 00:53:28 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7P7rQbW012516; Sun, 25 Aug 2013 10:53:26 +0300
X-CheckPoint: {5219B7F6-7-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.124]) with mapi id 14.02.0347.000; Sun, 25 Aug 2013 10:53:26 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Thread-Topic: [IPsec] CAFR -01 comments
Thread-Index: AQHOoV7LvmObZk5q9ECjoKHZT87lQpmlW1EA
Date: Sun, 25 Aug 2013 07:53:25 +0000
Message-ID: <1042A472-2B76-4746-92AC-D043A5484008@checkpoint.com>
References: <5219A814.2070603@gmail.com>
In-Reply-To: <5219A814.2070603@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.4]
x-kse-antivirus-interceptor-info: protection disabled
x-cpdlp: 111bb1a2a67725da6355a5c40587a975510ed8abf3
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8F2A2027930AD241B9B8FA57DC01127A@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] CAFR -01 comments
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: Sun, 25 Aug 2013 07:53:41 -0000

On Aug 25, 2013, at 9:45 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

> Hi Yoav,
>=20
> I started by reading -01, then went back to -00. And I think the two can =
be merged to create a better solution.
>=20
> Including the notification as soon as the peers know they want a handover=
 is cleaner. So IKE_AUTH (of the new SA) is better than DELETE, and in fact=
 IKE_SA_INIT would be even more useful because then you can define that all=
 such IKE SAs are implicitly childless, and avoid the need for the RFC 6023=
 notification.
>=20
> CAFR -01 says a peer is allowed to hand over the Child SAs if it successf=
ully authenticates to the other peer and has the same authenticated identit=
y. Seems to me this is symmetric, i.e. it doesn't matter if the exchange is=
 run over the "old" or the "new" IKE SA. And so this could apply just as we=
ll to -00, and the POP stuff is not needed.
>=20
> I'm not sure about the race discussion in -00, because it only applies in=
 failure cases. Can't an attacker "swallow" a few DELETE messages or their =
responses and cause a similar database mismatch?

I hope they can't. Informationals with DELETEs are just like any other IKEv=
2 exchange. If at active attacker swallows DELETEs or their responses, even=
tually at least one side loses the IKE SA.=20

But with regular initial IKE, there is an asymmetry. The Responder verifies=
 the IKE_AUTH request, generates the Response, sends it, and believes that =
everything is just fine. Then the Initiator gets the IKE_AUTH response, and=
 decides that something is wrong. Maybe the certificate has just expired, o=
r the OCSP server is unreachable, or the new certificate does not have the =
proper extended key usage. So we have an asymmetry, where the Responder bel=
ieves that IKE_AUTH succeeded, while the Initiator believes that it failed.=
 The Initiator quickly rectifies this with a DELETE, but that takes some ti=
me (milliseconds, but still - time).=20

So if we tie some action on the part of both parties to the IKE_AUTH succes=
s, we get cases where the Responder performs the action, while the Initiato=
r does not. In this case, the Responder transfers the child SAs to the new =
IKE SA, and the Initiator doesn't. The subsequent DELETE for the new IKE SA=
 sent by the Initiator deletes all those Child SAs on the Responder, while =
they remain alive and active on the Initiator. You could use some heuristic=
, like if the DELETE comes within x seconds of the IKE_AUTH, you transfer t=
he child SAs back. But that is some weird code that we should not require p=
eople to make.=20

Making the transfer follow the IKE_AUTH makes it all cleaner. Whether it's =
done with the old or new IKE SA depends on whether you are worried about ch=
ildless IKE SAs kidnapping the children of other IKE SAs (sorry, couldn't r=
esist). We are not likely to require sameness of IP address, and I am worri=
ed about the reliability of code comparing to IKE SAs for sameness of authe=
nticated identity. All L2TP over IPsec clients tend to have the same identi=
ty (with user authentication being done at the PPP layer). Do we allow them=
 to claim each other's child SAs? I think not, and then if we take the "pul=
l" approach - using the new IKE SA - we need some PoP. With a "push" approa=
ch - using the old IKE SA - we don't.

> Also note that the notification syntax is in conflict with both RFC 5996 =
and RFC 4306. RFC 5996 removes the option of Protocol ID=3D1, while RFC 430=
6 assumes that we are talking about the *current* IKE SA, and so mandates t=
hat the SPI field should be empty in this case. Practically speaking, we wi=
ll have to fix 5996 before this can document move forward. Luckily we're do=
ing just that with Tero's bis draft.

Good timing!

Yoav=

From yaronf.ietf@gmail.com  Sun Aug 25 01:11:53 2013
Return-Path: <yaronf.ietf@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 6517411E8236 for <ipsec@ietfa.amsl.com>; Sun, 25 Aug 2013 01:11:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DLYjrMv6NVO for <ipsec@ietfa.amsl.com>; Sun, 25 Aug 2013 01:11:52 -0700 (PDT)
Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id ED2C711E8233 for <ipsec@ietf.org>; Sun, 25 Aug 2013 01:11:51 -0700 (PDT)
Received: by mail-we0-f176.google.com with SMTP id q56so1797692wes.35 for <ipsec@ietf.org>; Sun, 25 Aug 2013 01:11:49 -0700 (PDT)
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=uLNneF7o35+ZGI6tq8THCwntLyvJVO2ahZORVzb3VvM=; b=H6iSSG6xdnlNv+WPc2LvMpkZ4nNUdZq8x358+DKfuh2FrmZiZ0saAPdf5T2vd/Aol3 iDp/wh7V96kzJgi9IDXqQ9zSAa/QigHmJBok92GAMqRyM7AE7bB+IyG/X6LT1W/FAOyX +pIZCMNVVokl52U9uubRAl3T+U/KW//AMn8/K5Mwn9LkbD9XQgPWnUN0pJzPHEDN9yxs d1CNZCv9HL0YY6cGrcmqiwM2obDOT0EMYfh3HnL3Uu9ZF/O+0x4uK+IFl+2nunjDRYAl UAon9H73qdV5RopGYq8sV03jLdcyoL9k0UTX/a62R90y9ly7LvZUH9qWnCxpcLZmgwSy irIg==
X-Received: by 10.180.39.36 with SMTP id m4mr3132299wik.6.1377418309642; Sun, 25 Aug 2013 01:11:49 -0700 (PDT)
Received: from [10.0.0.139] (93-173-253-212.bb.netvision.net.il. [93.173.253.212]) by mx.google.com with ESMTPSA id b13sm9003828wic.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Aug 2013 01:11:49 -0700 (PDT)
Message-ID: <5219BC43.3080700@gmail.com>
Date: Sun, 25 Aug 2013 11:11:47 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>
References: <5219A814.2070603@gmail.com> <1042A472-2B76-4746-92AC-D043A5484008@checkpoint.com>
In-Reply-To: <1042A472-2B76-4746-92AC-D043A5484008@checkpoint.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] CAFR -01 comments
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: Sun, 25 Aug 2013 08:11:53 -0000

Hi Yoav,

Regarding the notification syntax, it is actually a bit worse than that. 
This is a corner case in the RFC, but if you read Sec. 3.10 literally, 
there are exactly 2 allowed values for the Protocol ID field (or 3 
values, if you read RFC 4306). There is no extensibility defined, and no 
IANA registry either. So a responder would be correct if it replied with 
an INVALID_SYNTAX rather than ignoring your notification, if it doesn't 
recognize it.

And the value you are using (1) comes from RFC 2407 and has never 
existed in IKEv2. Ugh.

Thanks,
	Yaron

On 2013-08-25 10:53, Yoav Nir wrote:
>
> On Aug 25, 2013, at 9:45 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
>
>> Hi Yoav,
>>
>> I started by reading -01, then went back to -00. And I think the two can be merged to create a better solution.
>>
>> Including the notification as soon as the peers know they want a handover is cleaner. So IKE_AUTH (of the new SA) is better than DELETE, and in fact IKE_SA_INIT would be even more useful because then you can define that all such IKE SAs are implicitly childless, and avoid the need for the RFC 6023 notification.
>>
>> CAFR -01 says a peer is allowed to hand over the Child SAs if it successfully authenticates to the other peer and has the same authenticated identity. Seems to me this is symmetric, i.e. it doesn't matter if the exchange is run over the "old" or the "new" IKE SA. And so this could apply just as well to -00, and the POP stuff is not needed.
>>
>> I'm not sure about the race discussion in -00, because it only applies in failure cases. Can't an attacker "swallow" a few DELETE messages or their responses and cause a similar database mismatch?
>
> I hope they can't. Informationals with DELETEs are just like any other IKEv2 exchange. If at active attacker swallows DELETEs or their responses, eventually at least one side loses the IKE SA.
>
> But with regular initial IKE, there is an asymmetry. The Responder verifies the IKE_AUTH request, generates the Response, sends it, and believes that everything is just fine. Then the Initiator gets the IKE_AUTH response, and decides that something is wrong. Maybe the certificate has just expired, or the OCSP server is unreachable, or the new certificate does not have the proper extended key usage. So we have an asymmetry, where the Responder believes that IKE_AUTH succeeded, while the Initiator believes that it failed. The Initiator quickly rectifies this with a DELETE, but that takes some time (milliseconds, but still - time).
>
> So if we tie some action on the part of both parties to the IKE_AUTH success, we get cases where the Responder performs the action, while the Initiator does not. In this case, the Responder transfers the child SAs to the new IKE SA, and the Initiator doesn't. The subsequent DELETE for the new IKE SA sent by the Initiator deletes all those Child SAs on the Responder, while they remain alive and active on the Initiator. You could use some heuristic, like if the DELETE comes within x seconds of the IKE_AUTH, you transfer the child SAs back. But that is some weird code that we should not require people to make.
>
> Making the transfer follow the IKE_AUTH makes it all cleaner. Whether it's done with the old or new IKE SA depends on whether you are worried about childless IKE SAs kidnapping the children of other IKE SAs (sorry, couldn't resist). We are not likely to require sameness of IP address, and I am worried about the reliability of code comparing to IKE SAs for sameness of authenticated identity. All L2TP over IPsec clients tend to have the same identity (with user authentication being done at the PPP layer). Do we allow them to claim each other's child SAs? I think not, and then if we take the "pull" approach - using the new IKE SA - we need some PoP. With a "push" approach - using the old IKE SA - we don't.
>
>> Also note that the notification syntax is in conflict with both RFC 5996 and RFC 4306. RFC 5996 removes the option of Protocol ID=1, while RFC 4306 assumes that we are talking about the *current* IKE SA, and so mandates that the SPI field should be empty in this case. Practically speaking, we will have to fix 5996 before this can document move forward. Luckily we're doing just that with Tero's bis draft.
>
> Good timing!
>
> Yoav
>

From ynir@checkpoint.com  Sun Aug 25 01:47:55 2013
Return-Path: <ynir@checkpoint.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 0CC5B11E823E for <ipsec@ietfa.amsl.com>; Sun, 25 Aug 2013 01:47:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ESF4tJBUwQB for <ipsec@ietfa.amsl.com>; Sun, 25 Aug 2013 01:47:49 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E86ED21E804C for <ipsec@ietf.org>; Sun, 25 Aug 2013 01:47:45 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7P8lhCI003610; Sun, 25 Aug 2013 11:47:43 +0300
X-CheckPoint: {5219C4AF-0-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.124]) with mapi id 14.02.0347.000; Sun, 25 Aug 2013 11:47:43 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Thread-Topic: [IPsec] CAFR -01 comments
Thread-Index: AQHOoV7LvmObZk5q9ECjoKHZT87lQpmlW1EAgAAFI4CAADWjIA==
Date: Sun, 25 Aug 2013 08:47:42 +0000
Message-ID: <4613980CFC78314ABFD7F85CC302772121A1555E@DAG-EX10.ad.checkpoint.com>
References: <5219A814.2070603@gmail.com> <1042A472-2B76-4746-92AC-D043A5484008@checkpoint.com> <5219BC43.3080700@gmail.com>
In-Reply-To: <5219BC43.3080700@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [91.90.139.27]
x-kse-antivirus-interceptor-info: protection disabled
x-cpdlp: 11f97b3f55baa10cd565ca4ca82a552d88727bbab1
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] CAFR -01 comments
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: Sun, 25 Aug 2013 08:47:55 -0000

I read section 3.10 in RFC 4306, and it says this:

   o  Protocol ID (1 octet) - If this notification concerns an existing
      SA, this field indicates the type of that SA.  For IKE_SA
      notifications, this field MUST be one (1).  For notifications
      concerning IPsec SAs this field MUST contain either (2) to
      indicate AH or (3) to indicate ESP.  For notifications that do not
      relate to an existing SA, this field MUST be sent as zero and MUST
      be ignored on receipt.  All other values for this field are
      reserved to IANA for future assignment.

   o  SPI Size (1 octet) - Length in octets of the SPI as defined by the
      IPsec protocol ID or zero if no SPI is applicable.  For a
      notification concerning the IKE SA, the SPI Size MUST be zero and
      the field must be empty.

Sure there is a registry:  http://www.iana.org/assignments/ikev2-parameters=
/ikev2-parameters.xhtml#ikev2-parameters-18 . There are even values #4 and =
#5. But I see that bit about SPI size having to be zero, because it is assu=
med that notification about IKE SA only relate to *this* IKE SA.

So we can creatively interpret "the IKE SA" to be different from "an IKE SA=
", or we can ask IANA to add a new value with meaning "other IKE SA". Agree=
 it's a corner case.

-----Original Message-----
From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]=20
Sent: Sunday, August 25, 2013 11:12 AM
To: Yoav Nir
Cc: IPsecme WG
Subject: Re: [IPsec] CAFR -01 comments

Hi Yoav,

Regarding the notification syntax, it is actually a bit worse than that.=20
This is a corner case in the RFC, but if you read Sec. 3.10 literally, ther=
e are exactly 2 allowed values for the Protocol ID field (or 3 values, if y=
ou read RFC 4306). There is no extensibility defined, and no IANA registry =
either. So a responder would be correct if it replied with an INVALID_SYNTA=
X rather than ignoring your notification, if it doesn't recognize it.

And the value you are using (1) comes from RFC 2407 and has never existed i=
n IKEv2. Ugh.

Thanks,
	Yaron

On 2013-08-25 10:53, Yoav Nir wrote:
>
> On Aug 25, 2013, at 9:45 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
>
>> Hi Yoav,
>>
>> I started by reading -01, then went back to -00. And I think the two can=
 be merged to create a better solution.
>>
>> Including the notification as soon as the peers know they want a handove=
r is cleaner. So IKE_AUTH (of the new SA) is better than DELETE, and in fac=
t IKE_SA_INIT would be even more useful because then you can define that al=
l such IKE SAs are implicitly childless, and avoid the need for the RFC 602=
3 notification.
>>
>> CAFR -01 says a peer is allowed to hand over the Child SAs if it success=
fully authenticates to the other peer and has the same authenticated identi=
ty. Seems to me this is symmetric, i.e. it doesn't matter if the exchange i=
s run over the "old" or the "new" IKE SA. And so this could apply just as w=
ell to -00, and the POP stuff is not needed.
>>
>> I'm not sure about the race discussion in -00, because it only applies i=
n failure cases. Can't an attacker "swallow" a few DELETE messages or their=
 responses and cause a similar database mismatch?
>
> I hope they can't. Informationals with DELETEs are just like any other IK=
Ev2 exchange. If at active attacker swallows DELETEs or their responses, ev=
entually at least one side loses the IKE SA.
>
> But with regular initial IKE, there is an asymmetry. The Responder verifi=
es the IKE_AUTH request, generates the Response, sends it, and believes tha=
t everything is just fine. Then the Initiator gets the IKE_AUTH response, a=
nd decides that something is wrong. Maybe the certificate has just expired,=
 or the OCSP server is unreachable, or the new certificate does not have th=
e proper extended key usage. So we have an asymmetry, where the Responder b=
elieves that IKE_AUTH succeeded, while the Initiator believes that it faile=
d. The Initiator quickly rectifies this with a DELETE, but that takes some =
time (milliseconds, but still - time).
>
> So if we tie some action on the part of both parties to the IKE_AUTH succ=
ess, we get cases where the Responder performs the action, while the Initia=
tor does not. In this case, the Responder transfers the child SAs to the ne=
w IKE SA, and the Initiator doesn't. The subsequent DELETE for the new IKE =
SA sent by the Initiator deletes all those Child SAs on the Responder, whil=
e they remain alive and active on the Initiator. You could use some heurist=
ic, like if the DELETE comes within x seconds of the IKE_AUTH, you transfer=
 the child SAs back. But that is some weird code that we should not require=
 people to make.
>
> Making the transfer follow the IKE_AUTH makes it all cleaner. Whether it'=
s done with the old or new IKE SA depends on whether you are worried about =
childless IKE SAs kidnapping the children of other IKE SAs (sorry, couldn't=
 resist). We are not likely to require sameness of IP address, and I am wor=
ried about the reliability of code comparing to IKE SAs for sameness of aut=
henticated identity. All L2TP over IPsec clients tend to have the same iden=
tity (with user authentication being done at the PPP layer). Do we allow th=
em to claim each other's child SAs? I think not, and then if we take the "p=
ull" approach - using the new IKE SA - we need some PoP. With a "push" appr=
oach - using the old IKE SA - we don't.
>
>> Also note that the notification syntax is in conflict with both RFC 5996=
 and RFC 4306. RFC 5996 removes the option of Protocol ID=3D1, while RFC 43=
06 assumes that we are talking about the *current* IKE SA, and so mandates =
that the SPI field should be empty in this case. Practically speaking, we w=
ill have to fix 5996 before this can document move forward. Luckily we're d=
oing just that with Tero's bis draft.
>
> Good timing!
>
> Yoav
>

Email secured by Check Point

From yaronf.ietf@gmail.com  Sun Aug 25 02:07:11 2013
Return-Path: <yaronf.ietf@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 2382111E823C for <ipsec@ietfa.amsl.com>; Sun, 25 Aug 2013 02:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G09XqDUSCfc2 for <ipsec@ietfa.amsl.com>; Sun, 25 Aug 2013 02:07:10 -0700 (PDT)
Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id BA44A11E823A for <ipsec@ietf.org>; Sun, 25 Aug 2013 02:07:09 -0700 (PDT)
Received: by mail-we0-f181.google.com with SMTP id q57so1768541wes.26 for <ipsec@ietf.org>; Sun, 25 Aug 2013 02:07:08 -0700 (PDT)
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=zll+MV9ezYZ/5DxLkxLmwzWyCfHNMVXQ1u3Tlq/kRvg=; b=pkzSjPpkZmaq9+ADRDFEZTYJrkSMtrWCFV4C6SeUTksizUibGYSE+B6Zrx/yTgyH1/ 5fgkILD2f/eHcFW578SKUC8F6+Wult6KP/hXvEzHy10NNeYdvl0hoZ3xaxuh3iCnkU6Q y7fLRfhQscuIuya4Coy1JLTlmbL48AtJTYhPSV2qww2EsfsT/n0U9VElDeXtyWSmsPfy emQXLSt3ahmhAxudwbDLIePmrWM3sxTJy/VZu98dsBGw7M0b9YPpGqirn/jnGZkw4qPD OzfGvZQIYtxnZLy7cL6grYNwTXQbo9hZMZZEKEGm2n39bSidfr0/YmpzwTZtl16mD6oL SKEg==
X-Received: by 10.180.12.45 with SMTP id v13mr3672208wib.57.1377421628890; Sun, 25 Aug 2013 02:07:08 -0700 (PDT)
Received: from [10.0.0.139] (93-173-253-212.bb.netvision.net.il. [93.173.253.212]) by mx.google.com with ESMTPSA id ei6sm9286729wid.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Aug 2013 02:07:08 -0700 (PDT)
Message-ID: <5219C93A.4030809@gmail.com>
Date: Sun, 25 Aug 2013 12:07:06 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>
References: <5219A814.2070603@gmail.com> <1042A472-2B76-4746-92AC-D043A5484008@checkpoint.com> <5219BC43.3080700@gmail.com> <4613980CFC78314ABFD7F85CC302772121A1555E@DAG-EX10.ad.checkpoint.com>
In-Reply-To: <4613980CFC78314ABFD7F85CC302772121A1555E@DAG-EX10.ad.checkpoint.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] CAFR -01 comments
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: Sun, 25 Aug 2013 09:07:11 -0000

Thanks for pointing me to the registry!

I'm not worried about creative interpretations. More about existing 
implementations doing the wrong thing. So yes, maybe we should register 
a new value.

Thanks,
	Yaron

On 2013-08-25 11:47, Yoav Nir wrote:
> I read section 3.10 in RFC 4306, and it says this:
>
>     o  Protocol ID (1 octet) - If this notification concerns an existing
>        SA, this field indicates the type of that SA.  For IKE_SA
>        notifications, this field MUST be one (1).  For notifications
>        concerning IPsec SAs this field MUST contain either (2) to
>        indicate AH or (3) to indicate ESP.  For notifications that do not
>        relate to an existing SA, this field MUST be sent as zero and MUST
>        be ignored on receipt.  All other values for this field are
>        reserved to IANA for future assignment.
>
>     o  SPI Size (1 octet) - Length in octets of the SPI as defined by the
>        IPsec protocol ID or zero if no SPI is applicable.  For a
>        notification concerning the IKE SA, the SPI Size MUST be zero and
>        the field must be empty.
>
> Sure there is a registry:  http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-18 . There are even values #4 and #5. But I see that bit about SPI size having to be zero, because it is assumed that notification about IKE SA only relate to *this* IKE SA.
>
> So we can creatively interpret "the IKE SA" to be different from "an IKE SA", or we can ask IANA to add a new value with meaning "other IKE SA". Agree it's a corner case.
>
> -----Original Message-----
> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
> Sent: Sunday, August 25, 2013 11:12 AM
> To: Yoav Nir
> Cc: IPsecme WG
> Subject: Re: [IPsec] CAFR -01 comments
>
> Hi Yoav,
>
> Regarding the notification syntax, it is actually a bit worse than that.
> This is a corner case in the RFC, but if you read Sec. 3.10 literally, there are exactly 2 allowed values for the Protocol ID field (or 3 values, if you read RFC 4306). There is no extensibility defined, and no IANA registry either. So a responder would be correct if it replied with an INVALID_SYNTAX rather than ignoring your notification, if it doesn't recognize it.
>
> And the value you are using (1) comes from RFC 2407 and has never existed in IKEv2. Ugh.
>
> Thanks,
> 	Yaron
>
> On 2013-08-25 10:53, Yoav Nir wrote:
>>
>> On Aug 25, 2013, at 9:45 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
>>
>>> Hi Yoav,
>>>
>>> I started by reading -01, then went back to -00. And I think the two can be merged to create a better solution.
>>>
>>> Including the notification as soon as the peers know they want a handover is cleaner. So IKE_AUTH (of the new SA) is better than DELETE, and in fact IKE_SA_INIT would be even more useful because then you can define that all such IKE SAs are implicitly childless, and avoid the need for the RFC 6023 notification.
>>>
>>> CAFR -01 says a peer is allowed to hand over the Child SAs if it successfully authenticates to the other peer and has the same authenticated identity. Seems to me this is symmetric, i.e. it doesn't matter if the exchange is run over the "old" or the "new" IKE SA. And so this could apply just as well to -00, and the POP stuff is not needed.
>>>
>>> I'm not sure about the race discussion in -00, because it only applies in failure cases. Can't an attacker "swallow" a few DELETE messages or their responses and cause a similar database mismatch?
>>
>> I hope they can't. Informationals with DELETEs are just like any other IKEv2 exchange. If at active attacker swallows DELETEs or their responses, eventually at least one side loses the IKE SA.
>>
>> But with regular initial IKE, there is an asymmetry. The Responder verifies the IKE_AUTH request, generates the Response, sends it, and believes that everything is just fine. Then the Initiator gets the IKE_AUTH response, and decides that something is wrong. Maybe the certificate has just expired, or the OCSP server is unreachable, or the new certificate does not have the proper extended key usage. So we have an asymmetry, where the Responder believes that IKE_AUTH succeeded, while the Initiator believes that it failed. The Initiator quickly rectifies this with a DELETE, but that takes some time (milliseconds, but still - time).
>>
>> So if we tie some action on the part of both parties to the IKE_AUTH success, we get cases where the Responder performs the action, while the Initiator does not. In this case, the Responder transfers the child SAs to the new IKE SA, and the Initiator doesn't. The subsequent DELETE for the new IKE SA sent by the Initiator deletes all those Child SAs on the Responder, while they remain alive and active on the Initiator. You could use some heuristic, like if the DELETE comes within x seconds of the IKE_AUTH, you transfer the child SAs back. But that is some weird code that we should not require people to make.
>>
>> Making the transfer follow the IKE_AUTH makes it all cleaner. Whether it's done with the old or new IKE SA depends on whether you are worried about childless IKE SAs kidnapping the children of other IKE SAs (sorry, couldn't resist). We are not likely to require sameness of IP address, and I am worried about the reliability of code comparing to IKE SAs for sameness of authenticated identity. All L2TP over IPsec clients tend to have the same identity (with user authentication being done at the PPP layer). Do we allow them to claim each other's child SAs? I think not, and then if we take the "pull" approach - using the new IKE SA - we need some PoP. With a "push" approach - using the old IKE SA - we don't.
>>
>>> Also note that the notification syntax is in conflict with both RFC 5996 and RFC 4306. RFC 5996 removes the option of Protocol ID=1, while RFC 4306 assumes that we are talking about the *current* IKE SA, and so mandates that the SPI field should be empty in this case. Practically speaking, we will have to fix 5996 before this can document move forward. Luckily we're doing just that with Tero's bis draft.
>>
>> Good timing!
>>
>> Yoav
>>
>
> Email secured by Check Point
>

From ynir@checkpoint.com  Sun Aug 25 03:02:02 2013
Return-Path: <ynir@checkpoint.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 9D4D521F99A2 for <ipsec@ietfa.amsl.com>; Sun, 25 Aug 2013 03:02:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.655
X-Spam-Level: 
X-Spam-Status: No, score=-10.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeKHndnxthbL for <ipsec@ietfa.amsl.com>; Sun, 25 Aug 2013 03:01:57 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 464C121F9983 for <ipsec@ietf.org>; Sun, 25 Aug 2013 03:01:57 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7PA1sgF030326; Sun, 25 Aug 2013 13:01:54 +0300
X-CheckPoint: {5219D612-D-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.124]) with mapi id 14.02.0347.000; Sun, 25 Aug 2013 13:01:54 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Thread-Topic: [IPsec] CAFR -01 comments
Thread-Index: AQHOoV7LvmObZk5q9ECjoKHZT87lQpmlW1EAgAAFI4CAADWjIP//2dEAgAAPT4A=
Date: Sun, 25 Aug 2013 10:01:53 +0000
Message-ID: <6C870623-F681-4567-AC4A-F73902D161B2@checkpoint.com>
References: <5219A814.2070603@gmail.com> <1042A472-2B76-4746-92AC-D043A5484008@checkpoint.com> <5219BC43.3080700@gmail.com> <4613980CFC78314ABFD7F85CC302772121A1555E@DAG-EX10.ad.checkpoint.com> <5219C93A.4030809@gmail.com>
In-Reply-To: <5219C93A.4030809@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.34]
x-kse-antivirus-interceptor-info: protection disabled
x-cpdlp: 119dc5d0c102f35f1625cf69c57e16b508c15647e3
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <7EF32B0E49E74C4DBC0484712B8B8D41@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] CAFR -01 comments
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: Sun, 25 Aug 2013 10:02:02 -0000

Or do my other favorite thing with a "support_cafr" notification in the Ini=
tial exchange, so that support indicates that you understand protocol=3D1 a=
nd SPI size=3D16.

If we ever do an IKEv3, we need a "Features" payload, where optional capabi=
lities be listed in compact form.  That and replacing "Next Payload" with "=
This Payload"

Yoav

On Aug 25, 2013, at 12:07 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

> Thanks for pointing me to the registry!
>=20
> I'm not worried about creative interpretations. More about existing imple=
mentations doing the wrong thing. So yes, maybe we should register a new va=
lue.
>=20
> Thanks,
> 	Yaron
>=20
> On 2013-08-25 11:47, Yoav Nir wrote:
>> I read section 3.10 in RFC 4306, and it says this:
>>=20
>>    o  Protocol ID (1 octet) - If this notification concerns an existing
>>       SA, this field indicates the type of that SA.  For IKE_SA
>>       notifications, this field MUST be one (1).  For notifications
>>       concerning IPsec SAs this field MUST contain either (2) to
>>       indicate AH or (3) to indicate ESP.  For notifications that do not
>>       relate to an existing SA, this field MUST be sent as zero and MUST
>>       be ignored on receipt.  All other values for this field are
>>       reserved to IANA for future assignment.
>>=20
>>    o  SPI Size (1 octet) - Length in octets of the SPI as defined by the
>>       IPsec protocol ID or zero if no SPI is applicable.  For a
>>       notification concerning the IKE SA, the SPI Size MUST be zero and
>>       the field must be empty.
>>=20
>> Sure there is a registry:  http://www.iana.org/assignments/ikev2-paramet=
ers/ikev2-parameters.xhtml#ikev2-parameters-18 . There are even values #4 a=
nd #5. But I see that bit about SPI size having to be zero, because it is a=
ssumed that notification about IKE SA only relate to *this* IKE SA.
>>=20
>> So we can creatively interpret "the IKE SA" to be different from "an IKE=
 SA", or we can ask IANA to add a new value with meaning "other IKE SA". Ag=
ree it's a corner case.
>>=20
>> -----Original Message-----
>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
>> Sent: Sunday, August 25, 2013 11:12 AM
>> To: Yoav Nir
>> Cc: IPsecme WG
>> Subject: Re: [IPsec] CAFR -01 comments
>>=20
>> Hi Yoav,
>>=20
>> Regarding the notification syntax, it is actually a bit worse than that.
>> This is a corner case in the RFC, but if you read Sec. 3.10 literally, t=
here are exactly 2 allowed values for the Protocol ID field (or 3 values, i=
f you read RFC 4306). There is no extensibility defined, and no IANA regist=
ry either. So a responder would be correct if it replied with an INVALID_SY=
NTAX rather than ignoring your notification, if it doesn't recognize it.
>>=20
>> And the value you are using (1) comes from RFC 2407 and has never existe=
d in IKEv2. Ugh.
>>=20
>> Thanks,
>> 	Yaron
>>=20
>> On 2013-08-25 10:53, Yoav Nir wrote:
>>>=20
>>> On Aug 25, 2013, at 9:45 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrot=
e:
>>>=20
>>>> Hi Yoav,
>>>>=20
>>>> I started by reading -01, then went back to -00. And I think the two c=
an be merged to create a better solution.
>>>>=20
>>>> Including the notification as soon as the peers know they want a hando=
ver is cleaner. So IKE_AUTH (of the new SA) is better than DELETE, and in f=
act IKE_SA_INIT would be even more useful because then you can define that =
all such IKE SAs are implicitly childless, and avoid the need for the RFC 6=
023 notification.
>>>>=20
>>>> CAFR -01 says a peer is allowed to hand over the Child SAs if it succe=
ssfully authenticates to the other peer and has the same authenticated iden=
tity. Seems to me this is symmetric, i.e. it doesn't matter if the exchange=
 is run over the "old" or the "new" IKE SA. And so this could apply just as=
 well to -00, and the POP stuff is not needed.
>>>>=20
>>>> I'm not sure about the race discussion in -00, because it only applies=
 in failure cases. Can't an attacker "swallow" a few DELETE messages or the=
ir responses and cause a similar database mismatch?
>>>=20
>>> I hope they can't. Informationals with DELETEs are just like any other =
IKEv2 exchange. If at active attacker swallows DELETEs or their responses, =
eventually at least one side loses the IKE SA.
>>>=20
>>> But with regular initial IKE, there is an asymmetry. The Responder veri=
fies the IKE_AUTH request, generates the Response, sends it, and believes t=
hat everything is just fine. Then the Initiator gets the IKE_AUTH response,=
 and decides that something is wrong. Maybe the certificate has just expire=
d, or the OCSP server is unreachable, or the new certificate does not have =
the proper extended key usage. So we have an asymmetry, where the Responder=
 believes that IKE_AUTH succeeded, while the Initiator believes that it fai=
led. The Initiator quickly rectifies this with a DELETE, but that takes som=
e time (milliseconds, but still - time).
>>>=20
>>> So if we tie some action on the part of both parties to the IKE_AUTH su=
ccess, we get cases where the Responder performs the action, while the Init=
iator does not. In this case, the Responder transfers the child SAs to the =
new IKE SA, and the Initiator doesn't. The subsequent DELETE for the new IK=
E SA sent by the Initiator deletes all those Child SAs on the Responder, wh=
ile they remain alive and active on the Initiator. You could use some heuri=
stic, like if the DELETE comes within x seconds of the IKE_AUTH, you transf=
er the child SAs back. But that is some weird code that we should not requi=
re people to make.
>>>=20
>>> Making the transfer follow the IKE_AUTH makes it all cleaner. Whether i=
t's done with the old or new IKE SA depends on whether you are worried abou=
t childless IKE SAs kidnapping the children of other IKE SAs (sorry, couldn=
't resist). We are not likely to require sameness of IP address, and I am w=
orried about the reliability of code comparing to IKE SAs for sameness of a=
uthenticated identity. All L2TP over IPsec clients tend to have the same id=
entity (with user authentication being done at the PPP layer). Do we allow =
them to claim each other's child SAs? I think not, and then if we take the =
"pull" approach - using the new IKE SA - we need some PoP. With a "push" ap=
proach - using the old IKE SA - we don't.
>>>=20
>>>> Also note that the notification syntax is in conflict with both RFC 59=
96 and RFC 4306. RFC 5996 removes the option of Protocol ID=3D1, while RFC =
4306 assumes that we are talking about the *current* IKE SA, and so mandate=
s that the SPI field should be empty in this case. Practically speaking, we=
 will have to fix 5996 before this can document move forward. Luckily we're=
 doing just that with Tero's bis draft.
>>>=20
>>> Good timing!
>>>=20
>>> Yoav
>>>=20
>>=20
>> Email secured by Check Point
>>=20
>=20
> Email secured by Check Point


From yaronf.ietf@gmail.com  Sun Aug 25 03:08:25 2013
Return-Path: <yaronf.ietf@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 D91AA21F996A for <ipsec@ietfa.amsl.com>; Sun, 25 Aug 2013 03:08:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkttdSUc4oQZ for <ipsec@ietfa.amsl.com>; Sun, 25 Aug 2013 03:08:24 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 5261221F8BE6 for <ipsec@ietf.org>; Sun, 25 Aug 2013 03:08:24 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id l12so1712199wiv.13 for <ipsec@ietf.org>; Sun, 25 Aug 2013 03:08:22 -0700 (PDT)
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=xLYc2Lf/QwzAclmoVCIgVxGTIaDyfp8+oKDgwdsNY3E=; b=KBQi/+OER3R0zLcOxSCmP+ALmxnYx6a7md5QAGVbSJgXuodNsereeevgfpvaLUQhjc AedpYxyPuFO7C3duFpn0WqZZWrHHpwKOGkh+Bj+84EO1Dq1VZS6lBUTHTLJ91UjJP02L Nsxu1v1TUDP2hsxPlbY/eZUL+wZZoudsJLzg9HbbLumQN6pA14OtPcdGn2tJMk/Pk6df e9u+G+av2s3bA2UxA4ky92Ea9aD9P3Twedar0APu/6eZqmq2p+TNhFo1HKGET2ghCi63 GwVDpZyVlJqVo8fTgQxzW0CQ6kgLh5rXSxSLouJZEbfGCcqpK763M75I+FOkZyzfL5uz e0Dg==
X-Received: by 10.194.176.163 with SMTP id cj3mr5922251wjc.8.1377425302198; Sun, 25 Aug 2013 03:08:22 -0700 (PDT)
Received: from [10.0.0.139] (93-173-253-212.bb.netvision.net.il. [93.173.253.212]) by mx.google.com with ESMTPSA id ff5sm9694793wib.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Aug 2013 03:08:21 -0700 (PDT)
Message-ID: <5219D794.6030209@gmail.com>
Date: Sun, 25 Aug 2013 13:08:20 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>
References: <5219A814.2070603@gmail.com> <1042A472-2B76-4746-92AC-D043A5484008@checkpoint.com> <5219BC43.3080700@gmail.com> <4613980CFC78314ABFD7F85CC302772121A1555E@DAG-EX10.ad.checkpoint.com> <5219C93A.4030809@gmail.com> <6C870623-F681-4567-AC4A-F73902D161B2@checkpoint.com>
In-Reply-To: <6C870623-F681-4567-AC4A-F73902D161B2@checkpoint.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] CAFR -01 comments
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: Sun, 25 Aug 2013 10:08:26 -0000

And this would imply support for Childless, too?

Thanks,
	Yaron

On 2013-08-25 13:01, Yoav Nir wrote:
> Or do my other favorite thing with a "support_cafr" notification in the Initial exchange, so that support indicates that you understand protocol=1 and SPI size=16.
>
> If we ever do an IKEv3, we need a "Features" payload, where optional capabilities be listed in compact form.  That and replacing "Next Payload" with "This Payload"
>
> Yoav
>
> On Aug 25, 2013, at 12:07 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
>
>> Thanks for pointing me to the registry!
>>
>> I'm not worried about creative interpretations. More about existing implementations doing the wrong thing. So yes, maybe we should register a new value.
>>
>> Thanks,
>> 	Yaron
>>
>> On 2013-08-25 11:47, Yoav Nir wrote:
>>> I read section 3.10 in RFC 4306, and it says this:
>>>
>>>     o  Protocol ID (1 octet) - If this notification concerns an existing
>>>        SA, this field indicates the type of that SA.  For IKE_SA
>>>        notifications, this field MUST be one (1).  For notifications
>>>        concerning IPsec SAs this field MUST contain either (2) to
>>>        indicate AH or (3) to indicate ESP.  For notifications that do not
>>>        relate to an existing SA, this field MUST be sent as zero and MUST
>>>        be ignored on receipt.  All other values for this field are
>>>        reserved to IANA for future assignment.
>>>
>>>     o  SPI Size (1 octet) - Length in octets of the SPI as defined by the
>>>        IPsec protocol ID or zero if no SPI is applicable.  For a
>>>        notification concerning the IKE SA, the SPI Size MUST be zero and
>>>        the field must be empty.
>>>
>>> Sure there is a registry:  http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-18 . There are even values #4 and #5. But I see that bit about SPI size having to be zero, because it is assumed that notification about IKE SA only relate to *this* IKE SA.
>>>
>>> So we can creatively interpret "the IKE SA" to be different from "an IKE SA", or we can ask IANA to add a new value with meaning "other IKE SA". Agree it's a corner case.
>>>
>>> -----Original Message-----
>>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
>>> Sent: Sunday, August 25, 2013 11:12 AM
>>> To: Yoav Nir
>>> Cc: IPsecme WG
>>> Subject: Re: [IPsec] CAFR -01 comments
>>>
>>> Hi Yoav,
>>>
>>> Regarding the notification syntax, it is actually a bit worse than that.
>>> This is a corner case in the RFC, but if you read Sec. 3.10 literally, there are exactly 2 allowed values for the Protocol ID field (or 3 values, if you read RFC 4306). There is no extensibility defined, and no IANA registry either. So a responder would be correct if it replied with an INVALID_SYNTAX rather than ignoring your notification, if it doesn't recognize it.
>>>
>>> And the value you are using (1) comes from RFC 2407 and has never existed in IKEv2. Ugh.
>>>
>>> Thanks,
>>> 	Yaron
>>>
>>> On 2013-08-25 10:53, Yoav Nir wrote:
>>>>
>>>> On Aug 25, 2013, at 9:45 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
>>>>
>>>>> Hi Yoav,
>>>>>
>>>>> I started by reading -01, then went back to -00. And I think the two can be merged to create a better solution.
>>>>>
>>>>> Including the notification as soon as the peers know they want a handover is cleaner. So IKE_AUTH (of the new SA) is better than DELETE, and in fact IKE_SA_INIT would be even more useful because then you can define that all such IKE SAs are implicitly childless, and avoid the need for the RFC 6023 notification.
>>>>>
>>>>> CAFR -01 says a peer is allowed to hand over the Child SAs if it successfully authenticates to the other peer and has the same authenticated identity. Seems to me this is symmetric, i.e. it doesn't matter if the exchange is run over the "old" or the "new" IKE SA. And so this could apply just as well to -00, and the POP stuff is not needed.
>>>>>
>>>>> I'm not sure about the race discussion in -00, because it only applies in failure cases. Can't an attacker "swallow" a few DELETE messages or their responses and cause a similar database mismatch?
>>>>
>>>> I hope they can't. Informationals with DELETEs are just like any other IKEv2 exchange. If at active attacker swallows DELETEs or their responses, eventually at least one side loses the IKE SA.
>>>>
>>>> But with regular initial IKE, there is an asymmetry. The Responder verifies the IKE_AUTH request, generates the Response, sends it, and believes that everything is just fine. Then the Initiator gets the IKE_AUTH response, and decides that something is wrong. Maybe the certificate has just expired, or the OCSP server is unreachable, or the new certificate does not have the proper extended key usage. So we have an asymmetry, where the Responder believes that IKE_AUTH succeeded, while the Initiator believes that it failed. The Initiator quickly rectifies this with a DELETE, but that takes some time (milliseconds, but still - time).
>>>>
>>>> So if we tie some action on the part of both parties to the IKE_AUTH success, we get cases where the Responder performs the action, while the Initiator does not. In this case, the Responder transfers the child SAs to the new IKE SA, and the Initiator doesn't. The subsequent DELETE for the new IKE SA sent by the Initiator deletes all those Child SAs on the Responder, while they remain alive and active on the Initiator. You could use some heuristic, like if the DELETE comes within x seconds of the IKE_AUTH, you transfer the child SAs back. But that is some weird code that we should not require people to make.
>>>>
>>>> Making the transfer follow the IKE_AUTH makes it all cleaner. Whether it's done with the old or new IKE SA depends on whether you are worried about childless IKE SAs kidnapping the children of other IKE SAs (sorry, couldn't resist). We are not likely to require sameness of IP address, and I am worried about the reliability of code comparing to IKE SAs for sameness of authenticated identity. All L2TP over IPsec clients tend to have the same identity (with user authentication being done at the PPP layer). Do we allow them to claim each other's child SAs? I think not, and then if we take the "pull" approach - using the new IKE SA - we need some PoP. With a "push" approach - using the old IKE SA - we don't.
>>>>
>>>>> Also note that the notification syntax is in conflict with both RFC 5996 and RFC 4306. RFC 5996 removes the option of Protocol ID=1, while RFC 4306 assumes that we are talking about the *current* IKE SA, and so mandates that the SPI field should be empty in this case. Practically speaking, we will have to fix 5996 before this can document move forward. Luckily we're doing just that with Tero's bis draft.
>>>>
>>>> Good timing!
>>>>
>>>> Yoav
>>>>
>>>
>>> Email secured by Check Point
>>>
>>
>> Email secured by Check Point
>

From ynir@checkpoint.com  Sun Aug 25 03:12:29 2013
Return-Path: <ynir@checkpoint.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 F3B3E21F9B4B for <ipsec@ietfa.amsl.com>; Sun, 25 Aug 2013 03:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.653
X-Spam-Level: 
X-Spam-Status: No, score=-10.653 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SpgBnfdISox for <ipsec@ietfa.amsl.com>; Sun, 25 Aug 2013 03:12:24 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 772D421F99B0 for <ipsec@ietf.org>; Sun, 25 Aug 2013 03:12:23 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7PACDOa002288; Sun, 25 Aug 2013 13:12:21 +0300
X-CheckPoint: {5219D87D-20-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.124]) with mapi id 14.02.0347.000; Sun, 25 Aug 2013 13:12:14 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Thread-Topic: [IPsec] CAFR -01 comments
Thread-Index: AQHOoV7LvmObZk5q9ECjoKHZT87lQpmlW1EAgAAFI4CAADWjIP//2dEAgAAPT4CAAAHNAIAAARUA
Date: Sun, 25 Aug 2013 10:12:13 +0000
Message-ID: <D21BA4C6-9210-4273-8982-19FB0870BBC1@checkpoint.com>
References: <5219A814.2070603@gmail.com> <1042A472-2B76-4746-92AC-D043A5484008@checkpoint.com> <5219BC43.3080700@gmail.com> <4613980CFC78314ABFD7F85CC302772121A1555E@DAG-EX10.ad.checkpoint.com> <5219C93A.4030809@gmail.com> <6C870623-F681-4567-AC4A-F73902D161B2@checkpoint.com> <5219D794.6030209@gmail.com>
In-Reply-To: <5219D794.6030209@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.34]
x-kse-antivirus-interceptor-info: protection disabled
x-cpdlp: 110845b277ff32855ba13b2b8714b42e3f279e983a
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <640D6448B801A7409702BBD3A512FC85@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] CAFR -01 comments
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: Sun, 25 Aug 2013 10:12:29 -0000

I guess, but it's still using one notification to announce another notifica=
tion.

On Aug 25, 2013, at 1:08 PM, Yaron Sheffer <yaronf.ietf@gmail.com>
 wrote:

> And this would imply support for Childless, too?
>=20
> Thanks,
> 	Yaron
>=20
> On 2013-08-25 13:01, Yoav Nir wrote:
>> Or do my other favorite thing with a "support_cafr" notification in the =
Initial exchange, so that support indicates that you understand protocol=3D=
1 and SPI size=3D16.
>>=20
>> If we ever do an IKEv3, we need a "Features" payload, where optional cap=
abilities be listed in compact form.  That and replacing "Next Payload" wit=
h "This Payload"
>>=20
>> Yoav
>>=20
>> On Aug 25, 2013, at 12:07 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrot=
e:
>>=20
>>> Thanks for pointing me to the registry!
>>>=20
>>> I'm not worried about creative interpretations. More about existing imp=
lementations doing the wrong thing. So yes, maybe we should register a new =
value.
>>>=20
>>> Thanks,
>>> 	Yaron
>>>=20
>>> On 2013-08-25 11:47, Yoav Nir wrote:
>>>> I read section 3.10 in RFC 4306, and it says this:
>>>>=20
>>>>    o  Protocol ID (1 octet) - If this notification concerns an existin=
g
>>>>       SA, this field indicates the type of that SA.  For IKE_SA
>>>>       notifications, this field MUST be one (1).  For notifications
>>>>       concerning IPsec SAs this field MUST contain either (2) to
>>>>       indicate AH or (3) to indicate ESP.  For notifications that do n=
ot
>>>>       relate to an existing SA, this field MUST be sent as zero and MU=
ST
>>>>       be ignored on receipt.  All other values for this field are
>>>>       reserved to IANA for future assignment.
>>>>=20
>>>>    o  SPI Size (1 octet) - Length in octets of the SPI as defined by t=
he
>>>>       IPsec protocol ID or zero if no SPI is applicable.  For a
>>>>       notification concerning the IKE SA, the SPI Size MUST be zero an=
d
>>>>       the field must be empty.
>>>>=20
>>>> Sure there is a registry:  http://www.iana.org/assignments/ikev2-param=
eters/ikev2-parameters.xhtml#ikev2-parameters-18 . There are even values #4=
 and #5. But I see that bit about SPI size having to be zero, because it is=
 assumed that notification about IKE SA only relate to *this* IKE SA.
>>>>=20
>>>> So we can creatively interpret "the IKE SA" to be different from "an I=
KE SA", or we can ask IANA to add a new value with meaning "other IKE SA". =
Agree it's a corner case.
>>>>=20
>>>> -----Original Message-----
>>>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
>>>> Sent: Sunday, August 25, 2013 11:12 AM
>>>> To: Yoav Nir
>>>> Cc: IPsecme WG
>>>> Subject: Re: [IPsec] CAFR -01 comments
>>>>=20
>>>> Hi Yoav,
>>>>=20
>>>> Regarding the notification syntax, it is actually a bit worse than tha=
t.
>>>> This is a corner case in the RFC, but if you read Sec. 3.10 literally,=
 there are exactly 2 allowed values for the Protocol ID field (or 3 values,=
 if you read RFC 4306). There is no extensibility defined, and no IANA regi=
stry either. So a responder would be correct if it replied with an INVALID_=
SYNTAX rather than ignoring your notification, if it doesn't recognize it.
>>>>=20
>>>> And the value you are using (1) comes from RFC 2407 and has never exis=
ted in IKEv2. Ugh.
>>>>=20
>>>> Thanks,
>>>> 	Yaron
>>>>=20
>>>> On 2013-08-25 10:53, Yoav Nir wrote:
>>>>>=20
>>>>> On Aug 25, 2013, at 9:45 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wr=
ote:
>>>>>=20
>>>>>> Hi Yoav,
>>>>>>=20
>>>>>> I started by reading -01, then went back to -00. And I think the two=
 can be merged to create a better solution.
>>>>>>=20
>>>>>> Including the notification as soon as the peers know they want a han=
dover is cleaner. So IKE_AUTH (of the new SA) is better than DELETE, and in=
 fact IKE_SA_INIT would be even more useful because then you can define tha=
t all such IKE SAs are implicitly childless, and avoid the need for the RFC=
 6023 notification.
>>>>>>=20
>>>>>> CAFR -01 says a peer is allowed to hand over the Child SAs if it suc=
cessfully authenticates to the other peer and has the same authenticated id=
entity. Seems to me this is symmetric, i.e. it doesn't matter if the exchan=
ge is run over the "old" or the "new" IKE SA. And so this could apply just =
as well to -00, and the POP stuff is not needed.
>>>>>>=20
>>>>>> I'm not sure about the race discussion in -00, because it only appli=
es in failure cases. Can't an attacker "swallow" a few DELETE messages or t=
heir responses and cause a similar database mismatch?
>>>>>=20
>>>>> I hope they can't. Informationals with DELETEs are just like any othe=
r IKEv2 exchange. If at active attacker swallows DELETEs or their responses=
, eventually at least one side loses the IKE SA.
>>>>>=20
>>>>> But with regular initial IKE, there is an asymmetry. The Responder ve=
rifies the IKE_AUTH request, generates the Response, sends it, and believes=
 that everything is just fine. Then the Initiator gets the IKE_AUTH respons=
e, and decides that something is wrong. Maybe the certificate has just expi=
red, or the OCSP server is unreachable, or the new certificate does not hav=
e the proper extended key usage. So we have an asymmetry, where the Respond=
er believes that IKE_AUTH succeeded, while the Initiator believes that it f=
ailed. The Initiator quickly rectifies this with a DELETE, but that takes s=
ome time (milliseconds, but still - time).
>>>>>=20
>>>>> So if we tie some action on the part of both parties to the IKE_AUTH =
success, we get cases where the Responder performs the action, while the In=
itiator does not. In this case, the Responder transfers the child SAs to th=
e new IKE SA, and the Initiator doesn't. The subsequent DELETE for the new =
IKE SA sent by the Initiator deletes all those Child SAs on the Responder, =
while they remain alive and active on the Initiator. You could use some heu=
ristic, like if the DELETE comes within x seconds of the IKE_AUTH, you tran=
sfer the child SAs back. But that is some weird code that we should not req=
uire people to make.
>>>>>=20
>>>>> Making the transfer follow the IKE_AUTH makes it all cleaner. Whether=
 it's done with the old or new IKE SA depends on whether you are worried ab=
out childless IKE SAs kidnapping the children of other IKE SAs (sorry, coul=
dn't resist). We are not likely to require sameness of IP address, and I am=
 worried about the reliability of code comparing to IKE SAs for sameness of=
 authenticated identity. All L2TP over IPsec clients tend to have the same =
identity (with user authentication being done at the PPP layer). Do we allo=
w them to claim each other's child SAs? I think not, and then if we take th=
e "pull" approach - using the new IKE SA - we need some PoP. With a "push" =
approach - using the old IKE SA - we don't.
>>>>>=20
>>>>>> Also note that the notification syntax is in conflict with both RFC =
5996 and RFC 4306. RFC 5996 removes the option of Protocol ID=3D1, while RF=
C 4306 assumes that we are talking about the *current* IKE SA, and so manda=
tes that the SPI field should be empty in this case. Practically speaking, =
we will have to fix 5996 before this can document move forward. Luckily we'=
re doing just that with Tero's bis draft.
>>>>>=20
>>>>> Good timing!
>>>>>=20
>>>>> Yoav
>>>>>=20
>>>>=20
>>>> Email secured by Check Point
>>>>=20
>>>=20
>>> Email secured by Check Point
>>=20
>=20
> Email secured by Check Point


From yaronf.ietf@gmail.com  Sun Aug 25 03:13:34 2013
Return-Path: <yaronf.ietf@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 8962221F9C28 for <ipsec@ietfa.amsl.com>; Sun, 25 Aug 2013 03:13:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiH9UWw7+PUw for <ipsec@ietfa.amsl.com>; Sun, 25 Aug 2013 03:13:34 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id D0E6321F9C22 for <ipsec@ietf.org>; Sun, 25 Aug 2013 03:13:33 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id l12so3294014wiv.0 for <ipsec@ietf.org>; Sun, 25 Aug 2013 03:13:33 -0700 (PDT)
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=DQPpDffDINE6RKBo/M2YlYP0louwqDcL/d6j3Wwn1Xw=; b=oIaBL9afoKK0Q2CFXZ3aK5nML2SvYKb50im3QUdzzix+FmPZEUdPFmb8J1rytGImQR hyg+MM/bs6Nu00pE3h5gpp3jt+DKfvVDIwLsGSSZ1TR6xjQBINtub1bRODzydjfPGnAw Kkj1Dqy3VFz9VfJKncQh+xT8SnAWGc8fm9POK9b6crOXNkbNXY9c+vbLZ3ggewLgm7JX wtiI9W2NJV+kZ2ZaMQ6qlfhBCsWI3RO0gLF+/FQBxTNW3Qj6NWN2S/VkNmEv50Bj/MO3 wy1uS+pfCyObOzPk/bPNraUknn63agvlpOO63nBjoMqxYH2LmkQRw3QHxHEaaRvhxdcd R0nw==
X-Received: by 10.194.24.168 with SMTP id v8mr6033077wjf.28.1377425613001; Sun, 25 Aug 2013 03:13:33 -0700 (PDT)
Received: from [10.0.0.139] (93-173-253-212.bb.netvision.net.il. [93.173.253.212]) by mx.google.com with ESMTPSA id gg10sm9738300wib.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Aug 2013 03:13:32 -0700 (PDT)
Message-ID: <5219D8CB.40409@gmail.com>
Date: Sun, 25 Aug 2013 13:13:31 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>
References: <5219A814.2070603@gmail.com> <1042A472-2B76-4746-92AC-D043A5484008@checkpoint.com> <5219BC43.3080700@gmail.com> <4613980CFC78314ABFD7F85CC302772121A1555E@DAG-EX10.ad.checkpoint.com> <5219C93A.4030809@gmail.com> <6C870623-F681-4567-AC4A-F73902D161B2@checkpoint.com> <5219D794.6030209@gmail.com> <D21BA4C6-9210-4273-8982-19FB0870BBC1@checkpoint.com>
In-Reply-To: <D21BA4C6-9210-4273-8982-19FB0870BBC1@checkpoint.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] CAFR -01 comments
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: Sun, 25 Aug 2013 10:13:34 -0000

Ugly but safe.

	Yaron

On 2013-08-25 13:12, Yoav Nir wrote:
> I guess, but it's still using one notification to announce another notification.
>
> On Aug 25, 2013, at 1:08 PM, Yaron Sheffer <yaronf.ietf@gmail.com>
>   wrote:
>
>> And this would imply support for Childless, too?
>>
>> Thanks,
>> 	Yaron
>>
>> On 2013-08-25 13:01, Yoav Nir wrote:
>>> Or do my other favorite thing with a "support_cafr" notification in the Initial exchange, so that support indicates that you understand protocol=1 and SPI size=16.
>>>
>>> If we ever do an IKEv3, we need a "Features" payload, where optional capabilities be listed in compact form.  That and replacing "Next Payload" with "This Payload"
>>>
>>> Yoav
>>>

From svanru@gmail.com  Sun Aug 25 21:57:17 2013
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 3100311E8156 for <ipsec@ietfa.amsl.com>; Sun, 25 Aug 2013 21:57:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLTYOYu2MS0B for <ipsec@ietfa.amsl.com>; Sun, 25 Aug 2013 21:57:16 -0700 (PDT)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 22D5411E814C for <ipsec@ietf.org>; Sun, 25 Aug 2013 21:57:15 -0700 (PDT)
Received: by mail-la0-f48.google.com with SMTP id er20so1958540lab.7 for <ipsec@ietf.org>; Sun, 25 Aug 2013 21:57:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=vAQ/ruSqWVPCm4AmzH3garAyQ7LeZGkNTV+bB1pkE5w=; b=pQVcqzwq75SmK9qF2x9gqtSE5uuw+i8MK6gOugq6qYZWSMsDNRQ7yUWs7nY2qB5Jug eo9Rudpm8GXWhD7T2mtjz6/Y6T59EusujMWtioQfr3X6Fa0eMp7eg6mTHX+EpiEGySjv 9DfxqMfFGrdDM/JVLl85y1tAAwGWwcrYCK64q9BhnidAc/k9Hot6x+RWzoluKKtDTNIG mnvUeFye0P2gvVXK6hKPwHMTBzh4pi2lyQxb34fMnroCBplZIRzp/J2B7YCmwN5NtL7W +GSh3NOZQDikBHf9Jq+6/ErrdW06a5XEzs5hMqcjufRzAhKXSqQUl0b8R3n9lAIkmNdG Zqwg==
X-Received: by 10.152.116.7 with SMTP id js7mr12091330lab.11.1377493027658; Sun, 25 Aug 2013 21:57:07 -0700 (PDT)
Received: from chichi (ppp91-77-178-252.pppoe.mtu-net.ru. [91.77.178.252]) by mx.google.com with ESMTPSA id ay4sm4386751lbb.2.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 25 Aug 2013 21:57:06 -0700 (PDT)
Message-ID: <5ECBD9022E6044EDA994D55B2EFC3953@chichi>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Yoav Nir" <ynir@checkpoint.com>, "Yaron Sheffer" <yaronf.ietf@gmail.com>
References: <5219A814.2070603@gmail.com><1042A472-2B76-4746-92AC-D043A5484008@checkpoint.com><5219BC43.3080700@gmail.com> <4613980CFC78314ABFD7F85CC302772121A1555E@DAG-EX10.ad.checkpoint.com>
In-Reply-To: <4613980CFC78314ABFD7F85CC302772121A1555E@DAG-EX10.ad.checkpoint.com>
Date: Mon, 26 Aug 2013 08:57:03 +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
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3505.912
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] CAFR -01 comments
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: Mon, 26 Aug 2013 04:57:17 -0000

Hi Yoav, Yaron,

Sorry, I disagree. This notification is concerned with both "old" IKE SA (as 
Child SAs "sponsor") and
"new" IKE SA (as "acceptor"). So, to remain in concent with RFC5996 and to 
be logically consistent,
I'd suggest to make SPI field empty (and Protocol ID zero) and to move SPI 
for "new" IKE SA to Notification Data.
No new values for Protocol ID is needed.

Regards,
Valery.

> So we can creatively interpret "the IKE SA" to be different from "an IKE 
> SA", or we can ask IANA to add a new value with meaning "other IKE SA". 
> Agree it's a corner case.
>
> > Hi Yoav,
> >
> > Regarding the notification syntax, it is actually a bit worse than that.
> > This is a corner case in the RFC, but if you read Sec. 3.10 literally, 
> > there are exactly 2 allowed values for the Protocol ID field (or 3 
> > values, if you read RFC 4306).
> > There is no extensibility defined, and no IANA registry either. So a 
> > responder would be correct if it replied with an INVALID_SYNTAX rather 
> > than ignoring your
> > notification, if it doesn't recognize it.
> >
> > And the value you are using (1) comes from RFC 2407 and has never 
> > existed in IKEv2. Ugh.


From ynir@checkpoint.com  Mon Aug 26 21:38:50 2013
Return-Path: <ynir@checkpoint.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 5F4AA21E80A5 for <ipsec@ietfa.amsl.com>; Mon, 26 Aug 2013 21:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.65
X-Spam-Level: 
X-Spam-Status: No, score=-10.65 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvIWpveyY+Ic for <ipsec@ietfa.amsl.com>; Mon, 26 Aug 2013 21:38:44 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 09F4B21E80B3 for <ipsec@ietf.org>; Mon, 26 Aug 2013 21:38:43 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7R4cf5H001962 for <ipsec@ietf.org>; Tue, 27 Aug 2013 07:38:41 +0300
X-CheckPoint: {521C2D51-7-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.124]) with mapi id 14.02.0347.000; Tue, 27 Aug 2013 07:38:41 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: "<ipsec@ietf.org> WG" <ipsec@ietf.org>
Thread-Topic: Question about draft-kivinen-ipsecme-signature-auth
Thread-Index: AQHOot9N4ZyeGZQpvEK2RXwWNVWwmw==
Date: Tue, 27 Aug 2013 04:38:40 +0000
Message-ID: <CF96640B-2DCB-4579-AD08-B759B09A2DDF@checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.181]
x-kse-antivirus-interceptor-info: protection disabled
x-cpdlp: 115354e2ac5a62d27d4b2e602ed696b2be4beb1b5b
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5E586A72DD65774983AB7B3931023575@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [IPsec] Question about draft-kivinen-ipsecme-signature-auth
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: Tue, 27 Aug 2013 04:38:50 -0000

Hi

This draft is the result of a design team set up to suggest a solution for =
the working group. I notice that we haven't discussed this in the last meet=
ing.

I think we should adopt this document. Any reason why we shouldn't?

Yoav


From ynir@checkpoint.com  Mon Aug 26 22:09:02 2013
Return-Path: <ynir@checkpoint.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 5097121F99FA for <ipsec@ietfa.amsl.com>; Mon, 26 Aug 2013 22:09:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.648
X-Spam-Level: 
X-Spam-Status: No, score=-10.648 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2mx4vOQiRvr for <ipsec@ietfa.amsl.com>; Mon, 26 Aug 2013 22:08:56 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E618921F99DC for <ipsec@ietf.org>; Mon, 26 Aug 2013 22:08:53 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7R58oJh010462; Tue, 27 Aug 2013 08:08:50 +0300
X-CheckPoint: {521C3462-2-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.124]) with mapi id 14.02.0347.000; Tue, 27 Aug 2013 08:08:51 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Valery Smyslov <svanru@gmail.com>
Thread-Topic: [IPsec] CAFR -01 comments
Thread-Index: AQHOoV7LvmObZk5q9ECjoKHZT87lQpmlW1EAgAAFI4CAADWjIIABJkmAgAGVrAA=
Date: Tue, 27 Aug 2013 05:08:50 +0000
Message-ID: <29ADBC31-A8EF-4528-833C-D26FEDD2AF20@checkpoint.com>
References: <5219A814.2070603@gmail.com><1042A472-2B76-4746-92AC-D043A5484008@checkpoint.com><5219BC43.3080700@gmail.com> <4613980CFC78314ABFD7F85CC302772121A1555E@DAG-EX10.ad.checkpoint.com> <5ECBD9022E6044EDA994D55B2EFC3953@chichi>
In-Reply-To: <5ECBD9022E6044EDA994D55B2EFC3953@chichi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.181]
x-kse-antivirus-interceptor-info: protection disabled
x-cpdlp: 110a014d2e0efd51825f615224c0defa2359b11d25
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <A3DDA153DA91814BB94DEB7EF0FCADAC@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] CAFR -01 comments
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: Tue, 27 Aug 2013 05:09:02 -0000

You're right. It just seems so logical that if your data is an SPI, you sho=
uld use the field called "SPI".

I'll do that in -02.

Yoav

On Aug 26, 2013, at 7:57 AM, Valery Smyslov <svanru@gmail.com> wrote:

> Hi Yoav, Yaron,
>=20
> Sorry, I disagree. This notification is concerned with both "old" IKE SA =
(as Child SAs "sponsor") and
> "new" IKE SA (as "acceptor"). So, to remain in concent with RFC5996 and t=
o be logically consistent,
> I'd suggest to make SPI field empty (and Protocol ID zero) and to move SP=
I for "new" IKE SA to Notification Data.
> No new values for Protocol ID is needed.
>=20
> Regards,
> Valery.
>=20
>> So we can creatively interpret "the IKE SA" to be different from "an IKE=
 SA", or we can ask IANA to add a new value with meaning "other IKE SA". Ag=
ree it's a corner case.
>>=20
>> > Hi Yoav,
>> >
>> > Regarding the notification syntax, it is actually a bit worse than tha=
t.
>> > This is a corner case in the RFC, but if you read Sec. 3.10 literally,=
 > there are exactly 2 allowed values for the Protocol ID field (or 3 > val=
ues, if you read RFC 4306).
>> > There is no extensibility defined, and no IANA registry either. So a >=
 responder would be correct if it replied with an INVALID_SYNTAX rather > t=
han ignoring your
>> > notification, if it doesn't recognize it.
>> >
>> > And the value you are using (1) comes from RFC 2407 and has never > ex=
isted in IKEv2. Ugh.
>=20


From ynir@checkpoint.com  Tue Aug 27 02:06:41 2013
Return-Path: <ynir@checkpoint.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 EE18E21F9DD5 for <ipsec@ietfa.amsl.com>; Tue, 27 Aug 2013 02:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8siF+yrI+Yog for <ipsec@ietfa.amsl.com>; Tue, 27 Aug 2013 02:06:35 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5B65321F9A6A for <ipsec@ietf.org>; Tue, 27 Aug 2013 02:06:35 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7R96X80031105 for <ipsec@ietf.org>; Tue, 27 Aug 2013 12:06:33 +0300
X-CheckPoint: {521C6C19-77-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Tue, 27 Aug 2013 12:06:33 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: New Version Notification for draft-nir-ipsecme-cafr-02.txt
Thread-Index: AQHOowRgLNJoeXPdOEyXkISkRUy2Lpmoww0A
Date: Tue, 27 Aug 2013 09:06:33 +0000
Message-ID: <4613980CFC78314ABFD7F85CC302772121A1CF15@DAG-EX10.ad.checkpoint.com>
References: <20130827090353.3301.95348.idtracker@ietfa.amsl.com>
In-Reply-To: <20130827090353.3301.95348.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [91.90.139.27]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: [IPsec] FW: New Version Notification for draft-nir-ipsecme-cafr-02.txt
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: Tue, 27 Aug 2013 09:06:41 -0000

SGkNCg0KTmV3IHZlcnNpb24gb2YgdGhpcy4gQ2hhbmdlcyBhcmUgbWFpbmx5IHdpdGggZml4aW5n
IHRoZSBub3RpZmljYXRpb24gdG8gZml0IFJGQyA1OTk2IGJldHRlciwgYW5kIGEgYmV0dGVyIGV4
cGxhbmF0aW9uIG9mIEluaXRpYXRvciBhbmQgUmVzcG9uZGVyIGJlaGF2aW9yLg0KDQpZb2F2DQoN
Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v
cmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVHVlc2RheSwgQXVn
dXN0IDI3LCAyMDEzIDEyOjA0IFBNDQpUbzogWW9hdiBOaXINClN1YmplY3Q6IE5ldyBWZXJzaW9u
IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbmlyLWlwc2VjbWUtY2Fmci0wMi50eHQNCg0KDQpBIG5l
dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbmlyLWlwc2VjbWUtY2Fmci0wMi50eHQgaGFzIGJlZW4g
c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBZb2F2IE5pciBhbmQgcG9zdGVkIHRvIHRoZSBJRVRG
IHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtbmlyLWlwc2VjbWUtY2Fmcg0KUmV2aXNp
b246CSAwMg0KVGl0bGU6CQkgSGFuZGluZyBPdmVyIENoaWxkIFNBcyBGb2xsb3dpbmcgUmUtQXV0
aGVudGljYXRpb24gaW4gSUtFdjINCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTA4LTI3DQpHcm91cDoJ
CSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogNw0KVVJMOiAgICAgICAg
ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1uaXItaXBzZWNt
ZS1jYWZyLTAyLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v
cmcvZG9jL2RyYWZ0LW5pci1pcHNlY21lLWNhZnINCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbmlyLWlwc2VjbWUtY2Fmci0wMg0KRGlmZjogICAgICAg
ICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1uaXItaXBzZWNtZS1j
YWZyLTAyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYW4gZXh0ZW5z
aW9uIHRvIHRoZSBJS0V2MiBwcm90b2NvbCB3aGVyZWJ5DQogICBDaGlsZCBTQXMgYXJlIG1vdmVk
IHRvIHRoZSBuZXcgSUtFIFNBIGZvbGxvd2luZyByZS1hdXRoZW50aWNhdGlvbi4NCiAgIFRoaXMg
YWxsb3dzIGZvciBhIHNtb290aGVyIHRyYW5zaXRpb24gd2l0aCBubyBsb3NzIG9mIGNvbm5lY3Rp
dml0eS4NCg0K

From svanru@gmail.com  Tue Aug 27 08:39:05 2013
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 3C89921F9D21 for <ipsec@ietfa.amsl.com>; Tue, 27 Aug 2013 08:39:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERoujc5cnJd8 for <ipsec@ietfa.amsl.com>; Tue, 27 Aug 2013 08:39:04 -0700 (PDT)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 723C221F9D71 for <ipsec@ietf.org>; Tue, 27 Aug 2013 08:39:04 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id v1so2715381lbd.17 for <ipsec@ietf.org>; Tue, 27 Aug 2013 08:39:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :content-type:content-transfer-encoding:importance; bh=W347mv5Eh7w75LWisebTDJPl2YCOO3C9rcB5tsE0C8A=; b=lbJ9k4n/eJUyVlokmFmotFkpALsslvUWXAbu3ubbLpMJfPuICSALDws/3NY9EMYR7j dsz7OkM/83pDj/LFvi3zXku6eC2/6VONAX7hTDKPCMoYWyZcPa4WvnpFBHRvkNEWRV7r HlcAWC1vP6CxbCtH2szb6dGeIAWwlt+FY/HMhY3rqP2FjK1XLL/beaL4kBJAFwV4jND0 xDAYCVw1Kz0FiRp1/eF4a6RdPpOMk6Zq9BRTNpmD2/KkI9hwNsnSv93qYU4ecX1BSEQE UXcUsx7MoBDSYqDyI/UvGb/K4Gr6HGfAihDcX0Sj9IW2FiXeuJDFua/JmQvmKPklcfMA wWvQ==
X-Received: by 10.152.228.130 with SMTP id si2mr2602335lac.32.1377617943373; Tue, 27 Aug 2013 08:39:03 -0700 (PDT)
Received: from chichi (ppp91-77-168-96.pppoe.mtu-net.ru. [91.77.168.96]) by mx.google.com with ESMTPSA id b3sm8355484laf.7.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 27 Aug 2013 08:39:02 -0700 (PDT)
Message-ID: <788BBEF6EA1346DDBF0A1BF7EC26FD95@chichi>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Yoav Nir" <ynir@checkpoint.com>, <ipsec@ietf.org>
References: <CF96640B-2DCB-4579-AD08-B759B09A2DDF@checkpoint.com>
In-Reply-To: <CF96640B-2DCB-4579-AD08-B759B09A2DDF@checkpoint.com>
Date: Tue, 27 Aug 2013 19:38:57 +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
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3505.912
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912
Subject: Re: [IPsec] Question about draft-kivinen-ipsecme-signature-auth
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: Tue, 27 Aug 2013 15:39:05 -0000

> This draft is the result of a design team set up to suggest a solution for 
> the working group. I notice that we haven't discussed this in the last 
> meeting.
>
> I think we should adopt this document. Any reason why we shouldn't?

I support this.

But I also think that document should be updated to solve one more problem.
Currently the choice of authentication methods is arbitrary - both peers may 
choose
any method they consider appropriate. Unlike IKEv1 no negotiation is 
possible.
This is not a problem if any peer has only one private key, but if one peer 
has
several keys for different algorithms, while the other supports only subset 
of this
algorithms, they may run into trouble. The problem is that currently peer 
cannot
advertise which signature algorithms it supports. The world was simple when
almost everyone used RSA, but currently there are plenty on signature 
algorithms available,
and the situation I described is not uncommon. Even if it looks strange to 
have
multiple keys for everyday use in single VPN, consider the situation when
all hosts in the VPN need to change signature algorithms (for any reason, 
whether
the old was broken, or just became obsoleted by some authorities).
This cannot be done at once, so in transition period some hosts will
have both private keys. In some situations peer may deduce which key to use
by analyzing Certificate Request, but in general this is unreliable, as
this payload is optional and one CA may sign both keys.

Currently the draft allows peers to advertise the list of hash functions 
they support.
I'd sujjest to update the draft to include ability for peer to also 
advertise the list of signature
algorithms it supports.

Regards,
Valery. 


From ivo.sedlacek@ericsson.com  Thu Aug 29 00:24:41 2013
Return-Path: <ivo.sedlacek@ericsson.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 50FC811E80FF for <ipsec@ietfa.amsl.com>; Thu, 29 Aug 2013 00:24:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.514
X-Spam-Level: 
X-Spam-Status: No, score=-5.514 tagged_above=-999 required=5 tests=[AWL=0.734,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 347J+360SDsR for <ipsec@ietfa.amsl.com>; Thu, 29 Aug 2013 00:24:19 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 00FF111E810A for <IPsec@ietf.org>; Thu, 29 Aug 2013 00:24:07 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-f6-521ef716e49e
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E4.17.16099.617FE125; Thu, 29 Aug 2013 09:24:07 +0200 (CEST)
Received: from ESESSMB301.ericsson.se ([169.254.1.119]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Thu, 29 Aug 2013 09:24:06 +0200
From: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
To: "IPsec@ietf.org" <IPsec@ietf.org>
Thread-Topic: Question to RFC5996
Thread-Index: Ac6khtOqTWVIFolkTwy156qd63Ipiw==
Date: Thu, 29 Aug 2013 07:24:05 +0000
Message-ID: <39B5E4D390E9BD4890E2B31079006101135970@ESESSMB301.ericsson.se>
Accept-Language: en-US, cs-CZ
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101135970ESESSMB301ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvja74d7kgg4ZjnBb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRu/MPvaC39kV0/9/YmpgnJbQxcjJISFgItE2rZcZwhaTuHBv PRuILSRwmFHi5EK7LkYuIHsJo8T8I6+YQBJsAnoSE7ccYQWxRQRUJWZ3PAdrFhaQkZh/+DIb RFxRYv+vw0wQtp7EhU/fwGwWoPqeeXvAbF4Bb4ln8yDmMArISlz908sIYjMLiEvcejKfCeIg AYkle85DHScq8fLxP1YIW1Hi6vTlTBD1+RIn99xnh5gpKHFy5hOWCYxCs5CMmoWkbBaSMoi4 jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KkT03MTMnvdxwEyMw7A9u+a27g/HUOZFDjNIc LErivJv0zgQKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYCzL71M6feHNi71qOnxlHwRZqny/ bz+4P+Mcp9juqkkVmfurfN/t85jeJhWwRIc/c25zfu0du4Iyrr0pm8vVlt0RXcz5p2gP79bI t8vq7jL89nLgcWn+Zjf35oq8q6vFfeNPyblNKTv+wpB/jZ1p8u2qJy7vksTT3T62X5Kzlr8f ZyvavWUCtxJLcUaioRZzUXEiAFX8d3hJAgAA
Subject: [IPsec] Question to RFC5996
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: Thu, 29 Aug 2013 07:24:41 -0000

--_000_39B5E4D390E9BD4890E2B31079006101135970ESESSMB301ericsso_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,



RFC5996 gives structures of messages using tables. E.g. section 3.15.1 (see=
 excerpt below) gives the configuration attribute format as follows:

---------------------------------------------------------------------------=
--------------------------------------------

3.15.1.  Configuration Attributes



                        1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |R|         Attribute Type      |            Length             |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                                                               |

   ~                             Value                             ~

   |                                                               |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



            Figure 23:  Configuration Attribute Format

...

---------------------------------------------------------------------------=
--------------------------------------------



RFC5996 contains statement (see excerpt below) on octet order in multi-octe=
t fields, but does not seem to contain a statement on bit order in an octet=
. Thus, e.g. it is not clear whether the R field in the figure above the mo=
st significant bit or the least significant bit of the 1st octet.

--------------

3.1.  The IKE Header

...

   All multi-octet fields representing integers are laid out in big

   endian order (also known as "most significant byte first", or

   "network byte order").

...

--------------



I assume that RFC5996 follows http://www.rfc-editor.org/rfc-editor/instruct=
ions2authors.txt description stating "bit zero is the most significant bit =
in a word or a field". Is this correct understanding?



If so, the R field in the figure above would be the most significant bit of=
 the 1st octet.



Thanks for clarification.



Kind regards



Ivo Sedlacek


--_000_39B5E4D390E9BD4890E2B31079006101135970ESESSMB301ericsso_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
span.EmailStyle19
	{mso-style-type:personal-compose;
	font-family:"Arial","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Arial&quot;,&quot;sans-serif&quot;">Hello,<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Arial&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Arial&quot;,&quot;sans-serif&quot;">RFC5996 gives structures of messages u=
sing tables. E.g. section 3.15.1 (see excerpt below) gives the configuratio=
n attribute format as follows:<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;">-------------------------------------------------------=
----------------------------------------------------------------<o:p></o:p>=
</span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;">3.15.1.&nbsp; Configuration Attributes<o:p></o:p></span=
></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; 3<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;">&nbsp;&nbsp;&nbsp; 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 =
8 9 0 1 2 3 4 5 6 7 8 9 0 1<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;">&nbsp;&nbsp; &#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-=
&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#4=
3;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-=
&#43;<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;">&nbsp;&nbsp; |R|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; Attribute Type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Length&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;">&nbsp;&nbsp; &#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-=
&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#4=
3;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-=
&#43;<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;">&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;">&nbsp;&nbsp; ~&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Value&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; ~<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;">&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;">&nbsp;&nbsp; &#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-=
&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#4=
3;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-=
&#43;<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; Figure 23:&nbsp; Configuration Attribute Format<o:p></o:p></spa=
n></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;">...<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;">-------------------------------------------------------=
----------------------------------------------------------------<o:p></o:p>=
</span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Arial&quot;,&quot;sans-serif&quot;">RFC5996 contains statement (see excerp=
t below) on octet order in multi-octet fields, but does not seem to contain=
 a statement on bit order in an octet. Thus, e.g. it is
 not clear whether the R field in the figure above the most significant bit=
 or the least significant bit of the 1st octet.<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Arial&quot;,&quot;sans-serif&quot;">--------------<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;">3.1.&nbsp; The IKE Header<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;">...<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;">&nbsp;&nbsp; All multi-octet fields representing intege=
rs are laid out in big<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;">&nbsp;&nbsp; endian order (also known as &quot;most sig=
nificant byte first&quot;, or<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;">&nbsp;&nbsp; &quot;network byte order&quot;).
<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Courier New&quot;">...<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Arial&quot;,&quot;sans-serif&quot;">--------------<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Arial&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Arial&quot;,&quot;sans-serif&quot;">I assume that RFC5996 follows
<a href=3D"http://www.rfc-editor.org/rfc-editor/instructions2authors.txt">h=
ttp://www.rfc-editor.org/rfc-editor/instructions2authors.txt</a> descriptio=
n stating &quot;<u>bit zero is the most significant bit in a word or a fiel=
d</u>&quot;. Is this correct understanding?
<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Arial&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Arial&quot;,&quot;sans-serif&quot;">If so, the R field in the figure above=
 would be the most significant bit of the 1st octet.<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Arial&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Arial&quot;,&quot;sans-serif&quot;">Thanks for clarification.<o:p></o:p></=
span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Arial&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Arial&quot;,&quot;sans-serif&quot;">Kind regards<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Arial&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"font-size:10.0pt;font-family:&quot=
;Arial&quot;,&quot;sans-serif&quot;">Ivo Sedlacek<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ar=
ial&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
</div>
</body>
</html>

--_000_39B5E4D390E9BD4890E2B31079006101135970ESESSMB301ericsso_--

From ynir@checkpoint.com  Thu Aug 29 01:39:50 2013
Return-Path: <ynir@checkpoint.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 7FCCE11E80FE for <ipsec@ietfa.amsl.com>; Thu, 29 Aug 2013 01:39:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.64
X-Spam-Level: 
X-Spam-Status: No, score=-10.64 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vyf58+dOZqTd for <ipsec@ietfa.amsl.com>; Thu, 29 Aug 2013 01:39:45 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC0911E80FF for <IPsec@ietf.org>; Thu, 29 Aug 2013 01:39:44 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7T8dEaL004763; Thu, 29 Aug 2013 11:39:41 +0300
X-CheckPoint: {521F08B2-3-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Thu, 29 Aug 2013 11:39:33 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
Thread-Topic: [IPsec] Question to RFC5996
Thread-Index: Ac6khtOqTWVIFolkTwy156qd63Ipi///5qoA
Date: Thu, 29 Aug 2013 08:39:33 +0000
Message-ID: <187949FB-009A-48C0-BF7F-04AE6AA71BB4@checkpoint.com>
References: <39B5E4D390E9BD4890E2B31079006101135970@ESESSMB301.ericsson.se>
In-Reply-To: <39B5E4D390E9BD4890E2B31079006101135970@ESESSMB301.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.86]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: multipart/alternative; boundary="_000_187949FB009A48C0BF7F04AE6AA71BB4checkpointcom_"
MIME-Version: 1.0
Cc: "IPsec@ietf.org" <IPsec@ietf.org>
Subject: Re: [IPsec] Question to RFC5996
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: Thu, 29 Aug 2013 08:39:50 -0000

--_000_187949FB009A48C0BF7F04AE6AA71BB4checkpointcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Yes. R is the most significant bit.

Yoav

On Aug 29, 2013, at 10:24 AM, Ivo Sedlacek <ivo.sedlacek@ericsson.com<mailt=
o:ivo.sedlacek@ericsson.com>> wrote:

Hello,

RFC5996 gives structures of messages using tables. E.g. section 3.15.1 (see=
 excerpt below) gives the configuration attribute format as follows:
---------------------------------------------------------------------------=
--------------------------------------------
3.15.1.  Configuration Attributes

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|         Attribute Type      |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                             Value                             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 23:  Configuration Attribute Format
...
---------------------------------------------------------------------------=
--------------------------------------------

RFC5996 contains statement (see excerpt below) on octet order in multi-octe=
t fields, but does not seem to contain a statement on bit order in an octet=
. Thus, e.g. it is not clear whether the R field in the figure above the mo=
st significant bit or the least significant bit of the 1st octet.
--------------
3.1.  The IKE Header
...
   All multi-octet fields representing integers are laid out in big
   endian order (also known as "most significant byte first", or
   "network byte order").
...
--------------

I assume that RFC5996 follows http://www.rfc-editor.org/rfc-editor/instruct=
ions2authors.txt description stating "bit zero is the most significant bit =
in a word or a field". Is this correct understanding?

If so, the R field in the figure above would be the most significant bit of=
 the 1st octet.

Thanks for clarification.

Kind regards

Ivo Sedlacek

_______________________________________________
IPsec mailing list
IPsec@ietf.org<mailto:IPsec@ietf.org>
https://www.ietf.org/mailman/listinfo/ipsec


--_000_187949FB009A48C0BF7F04AE6AA71BB4checkpointcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <91187D2C796C5D4AB845690AE1FAC7BD@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<base href=3D"x-msg://452/">
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; ">
Yes. R is the most significant bit.
<div><br>
</div>
<div>Yoav</div>
<div><br>
<div>
<div>On Aug 29, 2013, at 10:24 AM, Ivo Sedlacek &lt;<a href=3D"mailto:ivo.s=
edlacek@ericsson.com">ivo.sedlacek@ericsson.com</a>&gt; wrote:</div>
<br class=3D"Apple-interchange-newline">
<blockquote type=3D"cite">
<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple" style=3D"font-family: Ta=
homa; font-size: medium; font-style: normal; font-variant: normal; font-wei=
ght: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-=
align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: n=
ormal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webki=
t-text-stroke-width: 0px; ">
<div class=3D"WordSection1" style=3D"page: WordSection1; ">
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: Arial, sans-serif; ">Hello,<o:=
p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: Arial, sans-serif; ">&nbsp;</s=
pan></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: Arial, sans-serif; ">RFC5996 g=
ives structures of messages using tables. E.g. section 3.15.1 (see excerpt =
below) gives the configuration attribute format as follows:<o:p></o:p></spa=
n></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">-------------=
---------------------------------------------------------------------------=
-------------------------------<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">3.15.1.&nbsp;=
 Configuration Attributes<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">&nbsp;</span>=
</div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">&nbsp;&nbsp;&=
nbsp; 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<o:p><=
/o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">&nbsp;&nbsp; =
&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#4=
3;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-=
&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">&nbsp;&nbsp; =
|R|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Attribute Type&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp; Length&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; |<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">&nbsp;&nbsp; =
&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#4=
3;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-=
&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">&nbsp;&nbsp; =
~&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; Value&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ~<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |=
<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">&nbsp;&nbsp; =
&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#4=
3;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-=
&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;-&#43;<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">&nbsp;</span>=
</div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Figure 23:&nbsp; Conf=
iguration Attribute Format<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">...<o:p></o:p=
></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">-------------=
---------------------------------------------------------------------------=
-------------------------------<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">&nbsp;</span>=
</div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: Arial, sans-serif; ">RFC5996 c=
ontains statement (see excerpt below) on octet order in multi-octet fields,=
 but does not seem to contain a statement on bit order in an octet. Thus, e=
.g. it is not clear whether the R
 field in the figure above the most significant bit or the least significan=
t bit of the 1st octet.<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: Arial, sans-serif; ">---------=
-----<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">3.1.&nbsp; Th=
e IKE Header<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">...<o:p></o:p=
></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">&nbsp;&nbsp; =
All multi-octet fields representing integers are laid out in big<o:p></o:p>=
</span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">&nbsp;&nbsp; =
endian order (also known as &quot;most significant byte first&quot;, or<o:p=
></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">&nbsp;&nbsp; =
&quot;network byte order&quot;).<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: 'Courier New'; ">...<o:p></o:p=
></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: Arial, sans-serif; ">---------=
-----<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: Arial, sans-serif; ">&nbsp;</s=
pan></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: Arial, sans-serif; ">I assume =
that RFC5996 follows<span class=3D"Apple-converted-space">&nbsp;</span><a h=
ref=3D"http://www.rfc-editor.org/rfc-editor/instructions2authors.txt" style=
=3D"color: purple; text-decoration: underline; ">http://www.rfc-editor.org/=
rfc-editor/instructions2authors.txt</a><span class=3D"Apple-converted-space=
">&nbsp;</span>description
 stating &quot;<u>bit zero is the most significant bit in a word or a field=
</u>&quot;. Is this correct understanding?<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: Arial, sans-serif; ">&nbsp;</s=
pan></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: Arial, sans-serif; ">If so, th=
e R field in the figure above would be the most significant bit of the 1st =
octet.<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: Arial, sans-serif; ">&nbsp;</s=
pan></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: Arial, sans-serif; ">Thanks fo=
r clarification.<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: Arial, sans-serif; ">&nbsp;</s=
pan></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: Arial, sans-serif; ">Kind rega=
rds<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: Arial, sans-serif; ">&nbsp;</s=
pan></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: Arial, sans-serif; ">Ivo Sedla=
cek<o:p></o:p></span></div>
<div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calib=
ri, sans-serif; ">
<span style=3D"font-size: 10pt; font-family: Arial, sans-serif; ">&nbsp;</s=
pan></div>
</div>
_______________________________________________<br>
IPsec mailing list<br>
<a href=3D"mailto:IPsec@ietf.org">IPsec@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/ipsec" style=3D"color: pur=
ple; text-decoration: underline; ">https://www.ietf.org/mailman/listinfo/ip=
sec</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>

--_000_187949FB009A48C0BF7F04AE6AA71BB4checkpointcom_--