From ipsec-bounces@ietf.org Fri Sep 08 04:26:36 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GLbbD-0001de-TT; Fri, 08 Sep 2006 04:20:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GLbbC-0001dY-FK
	for ipsec@ietf.org; Fri, 08 Sep 2006 04:20:30 -0400
Received: from py-out-1112.google.com ([64.233.166.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLbb9-0003Zg-8P
	for ipsec@ietf.org; Fri, 08 Sep 2006 04:20:30 -0400
Received: by py-out-1112.google.com with SMTP id e30so544608pya
	for <ipsec@ietf.org>; Fri, 08 Sep 2006 01:20:27 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=gGe2jxzop2rsTeoSMwxuA8seR5TzwpIo8UKyJig8lfR1+vhL+v9eC63mLJhLvhL13/gEaFdunjDpAJSsx5I2sLP/yfLBKa2rN7KeMWnGDPKYK8bR3zM8p3tUO0XFk523I6JvWAl/fOnTvaCb5nA+JjU12Cc8mF1pcru4rEgi6sw=
Received: by 10.65.51.16 with SMTP id d16mr1496178qbk;
	Fri, 08 Sep 2006 01:20:26 -0700 (PDT)
Received: by 10.65.197.2 with HTTP; Fri, 8 Sep 2006 01:20:26 -0700 (PDT)
Message-ID: <ae304c9d0609080120o267fa411lbd30c153efbb4659@mail.gmail.com>
Date: Fri, 8 Sep 2006 16:20:26 +0800
From: "q p" <qiaopengxp@gmail.com>
To: ipsec@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Subject: [Ipsec] xfrm
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1862000981=="
Errors-To: ipsec-bounces@ietf.org

--===============1862000981==
Content-Type: multipart/alternative; 
	boundary="----=_Part_172069_9397336.1157703626798"

------=_Part_172069_9397336.1157703626798
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi all
      I'm really confused with the XFRM mechanics used in IPSEC.
  Is anyone konw about it? What should I do to understand this?
  Any information or suggestions will be appreciated.

      Thank you all.

------=_Part_172069_9397336.1157703626798
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div>Hi all</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I'm really confused with the XFRM&nbsp;mechanics used in IPSEC.</div>
<div>&nbsp; Is anyone konw about it? What should I do to understand this?</div>
<div>&nbsp; Any information or suggestions will be appreciated.</div>
<div>&nbsp; </div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Thank you all.</div>

------=_Part_172069_9397336.1157703626798--


--===============1862000981==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec

--===============1862000981==--




From ipsec-bounces@ietf.org Sat Sep 09 02:00:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GLvpo-0002xC-6Y; Sat, 09 Sep 2006 01:56:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GLvpn-0002x7-Bj
	for ipsec@ietf.org; Sat, 09 Sep 2006 01:56:55 -0400
Received: from wx-out-0506.google.com ([66.249.82.233])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLvpj-0001DU-33
	for ipsec@ietf.org; Sat, 09 Sep 2006 01:56:55 -0400
Received: by wx-out-0506.google.com with SMTP id t4so1013684wxc
	for <ipsec@ietf.org>; Fri, 08 Sep 2006 22:56:50 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=tFnXP+0vFBFIvQx4/xX0Ok2V2rayebJlZg7zx3GOJi8rHauqSFTyu6SAOIzj3IBHlXZCn01Id4ILAzAYAWZPMWOXgc+efq0BHktokQn2jjw9XkXdyZBxVApoI5IRQLednbWtGLYHO+uZp42itSKI5N+R90ZG72SV9rgMTDwe64c=
Received: by 10.70.68.9 with SMTP id q9mr1274191wxa;
	Fri, 08 Sep 2006 22:56:50 -0700 (PDT)
Received: by 10.70.91.2 with HTTP; Fri, 8 Sep 2006 22:56:50 -0700 (PDT)
Message-ID: <cc7d483f0609082256g3ff0fe93yf50929346c162102@mail.gmail.com>
Date: Sat, 9 Sep 2006 11:26:50 +0530
From: "Vikas Khanna" <vik.kha@gmail.com>
To: "q p" <qiaopengxp@gmail.com>
Subject: Re: [Ipsec] xfrm
In-Reply-To: <ae304c9d0609080120o267fa411lbd30c153efbb4659@mail.gmail.com>
MIME-Version: 1.0
References: <ae304c9d0609080120o267fa411lbd30c153efbb4659@mail.gmail.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: ipsec@ietf.org
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1699730435=="
Errors-To: ipsec-bounces@ietf.org

--===============1699730435==
Content-Type: multipart/alternative; 
	boundary="----=_Part_181292_22248693.1157781410748"

------=_Part_181292_22248693.1157781410748
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,
Like you, I am also interested in understanding the xfrm standard. Strangely
there are not enough information that is available on net. The only
documents I got hold of are
USAGI IPv6 IPsec Development for Linux  (
http://doi.ieeecomputersociety.org/10.1109/SAINTW.2004.1268582 )
IPv6 IPsec and Mobile IPv6 implementation of Linux
These documents just give you the brief idea about the architecture and how
it is used along with stackable destination architecture to process IPSec
packets.

Regards,
Vik


On 9/8/06, q p <qiaopengxp@gmail.com> wrote:
>
> Hi all
>       I'm really confused with the XFRM mechanics used in IPSEC.
>   Is anyone konw about it? What should I do to understand this?
>   Any information or suggestions will be appreciated.
>
>       Thank you all.
>
> _______________________________________________
> Ipsec mailing list
> Ipsec@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipsec
>
>
>

------=_Part_181292_22248693.1157781410748
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline



<p class="MsoNormal">Hi,<br>
Like you, I am also interested in understanding the xfrm standard. Strangely
there are not enough information that is available on net. The only documents I
got hold of are <br>
<span class="title">USAGI IPv6 IPsec Development for Linux</span>&nbsp;
(<a href="http://doi.ieeecomputersociety.org/10.1109/SAINTW.2004.1268582">http://doi.ieeecomputersociety.org/10.1109/SAINTW.2004.1268582</a> )<br>
IPv6 IPsec and Mobile IPv6 implementation of Linux<br>
These documents just give you the brief idea about the architecture and how it
is used along with stackable destination architecture to process IPSec packets.
<br>
<br>
Regards,<br>
Vik<span style="font-size: 10pt; font-family: Arial;"></span></p>

<br><br><div><span class="gmail_quote">On 9/8/06, <b class="gmail_sendername">q p</b> &lt;<a href="mailto:qiaopengxp@gmail.com">qiaopengxp@gmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div>Hi all</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I'm really confused with the XFRM&nbsp;mechanics used in IPSEC.</div>
<div>&nbsp; Is anyone konw about it? What should I do to understand this?</div>
<div>&nbsp; Any information or suggestions will be appreciated.</div>
<div>&nbsp; </div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Thank you all.</div>

</div><br>_______________________________________________<br>Ipsec mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:Ipsec@ietf.org">Ipsec@ietf.org</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="https://www1.ietf.org/mailman/listinfo/ipsec" target="_blank">
https://www1.ietf.org/mailman/listinfo/ipsec</a><br><br><br></blockquote></div><br>

------=_Part_181292_22248693.1157781410748--


--===============1699730435==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec

--===============1699730435==--




From ipsec-bounces@ietf.org Mon Sep 25 07:02:36 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GRoBB-00015x-Rh; Mon, 25 Sep 2006 06:59:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GRoBA-000128-0c
	for ipsec@ietf.org; Mon, 25 Sep 2006 06:59:16 -0400
Received: from web8806.mail.in.yahoo.com ([203.84.221.15])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GRoB8-0007zc-Ak
	for ipsec@ietf.org; Mon, 25 Sep 2006 06:59:15 -0400
Received: (qmail 88821 invoked by uid 60001); 25 Sep 2006 10:59:13 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in;
	h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;
	b=oN/3r1ky4VELdrHfbMJYEX46h/By9gJZ0koHyG23/isfAZwDBj6UT2M/3YkJWwesN1Mxz+a4MiVVju5bvGpikFjqeswuogo4j3RMnwJq/uhHaj0xcjayH6CdE4Xe/+pC0BxqUJsakRxWejYmjZhmPBiS2KN2yGrBxhhTXP21R3o=
	; 
Message-ID: <20060925105913.88819.qmail@web8806.mail.in.yahoo.com>
Received: from [124.30.5.98] by web8806.mail.in.yahoo.com via HTTP;
	Mon, 25 Sep 2006 16:29:13 IST
Date: Mon, 25 Sep 2006 16:29:13 +0530 (IST)
From: Pooja Kamra <poojakamra1981@yahoo.co.in>
To: ipsec@ietf.org
MIME-Version: 1.0
X-Spam-Score: 2.4 (++)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Subject: [Ipsec] Implementaton of AES-XCBC-MAC-96
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Pooja Kamra <poojakamra1981@yahoo.co.in>
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1979267843=="
Errors-To: ipsec-bounces@ietf.org

--===============1979267843==
Content-Type: multipart/alternative; boundary="0-776238931-1159181953=:87047"

--0-776238931-1159181953=:87047
Content-Type: text/plain; charset=us-ascii

Hi,
 
In the RFC 3566, while generating K1, K2, and K3 from secret key K, what is the IV to be used. In the test vectors given in the RFC, IV is not specified. So, for generating three keys, do we have to use AES encryption in ECB mode, that doesn't need IV, or we have to use 
"E[0] = 0x00000000000000000000000000000000" as the IV.
 
Is there any sample implementation of the same available.
 
Regards
Pooja
--0-776238931-1159181953=:87047
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">
<STYLE type=text/css><!-- DIV {margin:0px;}--></STYLE>

<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>In the RFC 3566, while generating K1, K2, and K3 from secret key K, what is the IV to be used. In the test vectors given in the RFC, IV is not specified. So, for generating three keys, do we have to use AES encryption in ECB mode, that doesn't need IV, or we have to use <FONT face=Courier size=2>
<P align=left>"E[0] = 0x00000000000000000000000000000000" as the IV.</P>
<P align=left>&nbsp;</P>
<P align=left>Is there any sample implementation of the same available.</P>
<P align=left>&nbsp;</P>
<P align=left>Regards</P>
<P align=left>Pooja</P></FONT></DIV></DIV></DIV><BR></DIV></div></body></html>
--0-776238931-1159181953=:87047--


--===============1979267843==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec

--===============1979267843==--




From ipsec-bounces@ietf.org Mon Sep 25 09:17:29 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GRqIr-0007Za-Sm; Mon, 25 Sep 2006 09:15:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqIr-0007ZS-Dc
	for ipsec@ietf.org; Mon, 25 Sep 2006 09:15:21 -0400
Received: from mgw-ext13.nokia.com ([131.228.20.172])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRqIp-0005ZH-WB
	for ipsec@ietf.org; Mon, 25 Sep 2006 09:15:21 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id
	k8PDFICB023275; Mon, 25 Sep 2006 16:15:19 +0300
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 25 Sep 2006 16:15:18 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by
	esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 25 Sep 2006 16:15:18 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ipsec] Implementaton of AES-XCBC-MAC-96
Date: Mon, 25 Sep 2006 16:15:14 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F24032BDD71@esebe105.NOE.Nokia.com>
In-Reply-To: <20060925105913.88819.qmail@web8806.mail.in.yahoo.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ipsec] Implementaton of AES-XCBC-MAC-96
Thread-Index: AcbgkzFEkAU9u0uGT/ukkn1uYcCtbQAEBJRw
From: <Pasi.Eronen@nokia.com>
To: <poojakamra1981@yahoo.co.in>, <ipsec@ietf.org>
X-OriginalArrivalTime: 25 Sep 2006 13:15:18.0674 (UTC)
	FILETIME=[A5C04F20:01C6E0A4]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: 
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org

Pooja Kamra [mailto:poojakamra1981@yahoo.co.in] wrote:
> Hi,
>     =20
> In the RFC 3566, while generating K1, K2, and K3 from secret key K,
> what is the IV to be used. In the test vectors given in the RFC, IV
> is not specified. So, for generating three keys, do we have to use
> AES encryption in ECB mode, that doesn't need IV, or we have to use
> "E[0] =3D 0x00000000000000000000000000000000" as the IV.

It's just a single "raw" AES encryption operation (I guess you
could call it ECB in this context).

> Is there any sample implementation of the same available.

FreeBSD's IPsec supports XCBC-MAC.

Best regards,
Pasi

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Mon Sep 25 09:48:17 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GRqo1-0004Qy-Rz; Mon, 25 Sep 2006 09:47:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqo0-0004Qh-5P
	for ipsec@ietf.org; Mon, 25 Sep 2006 09:47:32 -0400
Received: from michael.checkpoint.com ([194.29.32.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRqny-00025n-Jy
	for ipsec@ietf.org; Mon, 25 Sep 2006 09:47:32 -0400
Received: from [194.29.46.218] (localhost [127.0.0.1])
	by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id
	k8PDlJKP001568; Mon, 25 Sep 2006 16:47:19 +0300 (IDT)
In-Reply-To: <B356D8F434D20B40A8CEDAEC305A1F24032BDD71@esebe105.NOE.Nokia.com>
References: <B356D8F434D20B40A8CEDAEC305A1F24032BDD71@esebe105.NOE.Nokia.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C6B271DB-5DF9-4CA6-BE77-D64B4AE7F254@checkpoint.com>
Content-Transfer-Encoding: 7bit
From: Yoav Nir <ynir@checkpoint.com>
Subject: Re: [Ipsec] Implementaton of AES-XCBC-MAC-96
Date: Mon, 25 Sep 2006 16:47:13 +0300
To: "<Pasi.Eronen@nokia.com>" <Pasi.Eronen@nokia.com>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: ipsec@ietf.org, poojakamra1981@yahoo.co.in
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org

On Sep 25, 2006, at 4:15 PM, <Pasi.Eronen@nokia.com>  
<Pasi.Eronen@nokia.com> wrote:

> Pooja Kamra [mailto:poojakamra1981@yahoo.co.in] wrote:
>> Hi,
>>
>> In the RFC 3566, while generating K1, K2, and K3 from secret key K,
>> what is the IV to be used. In the test vectors given in the RFC, IV
>> is not specified. So, for generating three keys, do we have to use
>> AES encryption in ECB mode, that doesn't need IV, or we have to use
>> "E[0] = 0x00000000000000000000000000000000" as the IV.
>
> It's just a single "raw" AES encryption operation (I guess you
> could call it ECB in this context).

You still have to XOR the previous encrypted block from the message  
with the next plaintext block of the message, so it's not like ECB.   
It's like CBC.

The best description is that it's CBC with an IV of zero.  E[0] here  
serves the same purpose as an IV in CBC.



_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Mon Sep 25 09:55:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GRqvR-0000Bo-JF; Mon, 25 Sep 2006 09:55:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqvP-0000BZ-DN
	for ipsec@ietf.org; Mon, 25 Sep 2006 09:55:11 -0400
Received: from mgw-ext13.nokia.com ([131.228.20.172])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRqvN-0003Vo-Uu
	for ipsec@ietf.org; Mon, 25 Sep 2006 09:55:11 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id
	k8PDsLGH013012; Mon, 25 Sep 2006 16:54:22 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 25 Sep 2006 16:54:22 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by
	esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 25 Sep 2006 16:54:21 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ipsec] Implementaton of AES-XCBC-MAC-96
Date: Mon, 25 Sep 2006 16:54:20 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F24032BDDA9@esebe105.NOE.Nokia.com>
In-Reply-To: <C6B271DB-5DF9-4CA6-BE77-D64B4AE7F254@checkpoint.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ipsec] Implementaton of AES-XCBC-MAC-96
Thread-Index: AcbgqTSHNz2fxBF9QeywqI3uviGx4QAAIk5A
From: <Pasi.Eronen@nokia.com>
To: <ynir@checkpoint.com>, <poojakamra1981@yahoo.co.in>, <ipsec@ietf.org>
X-OriginalArrivalTime: 25 Sep 2006 13:54:21.0559 (UTC)
	FILETIME=[1A383070:01C6E0AA]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: 
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org

Yoav Nir wrote:
> > It's just a single "raw" AES encryption operation (I guess you
> > could call it ECB in this context).
>=20
> You still have to XOR the previous encrypted block from the message =20
> with the next plaintext block of the message, so it's not like ECB.  =20
> It's like CBC.
>
> The best description is that it's CBC with an IV of zero.  E[0] here =20
> serves the same purpose as an IV in CBC.

That's true about the actual MAC calculation (steps 2..5), but
the original question was about the K1/K2/K3 calculation (step 1),
where you don't XOR any previous blocks (and you have only
a single block).

Best regards,
Pasi

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Mon Sep 25 09:59:10 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GRqz9-0003C3-Eb; Mon, 25 Sep 2006 09:59:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqz7-0003Br-T7
	for ipsec@ietf.org; Mon, 25 Sep 2006 09:59:01 -0400
Received: from michael.checkpoint.com ([194.29.32.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRqz6-00044q-CN
	for ipsec@ietf.org; Mon, 25 Sep 2006 09:59:01 -0400
Received: from [194.29.46.218] (localhost [127.0.0.1])
	by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id
	k8PDwxKP006051; Mon, 25 Sep 2006 16:58:59 +0300 (IDT)
In-Reply-To: <B356D8F434D20B40A8CEDAEC305A1F24032BDDA9@esebe105.NOE.Nokia.com>
References: <B356D8F434D20B40A8CEDAEC305A1F24032BDDA9@esebe105.NOE.Nokia.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <3096C32F-548A-4BAE-BCFB-45694D546AC8@checkpoint.com>
Content-Transfer-Encoding: 7bit
From: Yoav Nir <ynir@checkpoint.com>
Subject: Re: [Ipsec] Implementaton of AES-XCBC-MAC-96
Date: Mon, 25 Sep 2006 16:58:53 +0300
To: "<Pasi.Eronen@nokia.com>" <Pasi.Eronen@nokia.com>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: ipsec@ietf.org, poojakamra1981@yahoo.co.in
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org

On Sep 25, 2006, at 4:54 PM, <Pasi.Eronen@nokia.com>  
<Pasi.Eronen@nokia.com> wrote:

> Yoav Nir wrote:
>>> It's just a single "raw" AES encryption operation (I guess you
>>> could call it ECB in this context).
>>
>> You still have to XOR the previous encrypted block from the message
>> with the next plaintext block of the message, so it's not like ECB.
>> It's like CBC.
>>
>> The best description is that it's CBC with an IV of zero.  E[0] here
>> serves the same purpose as an IV in CBC.
>
> That's true about the actual MAC calculation (steps 2..5), but
> the original question was about the K1/K2/K3 calculation (step 1),
> where you don't XOR any previous blocks (and you have only
> a single block).
>
> Best regards,
> Pasi
>

Oops.  You're right.  Should have read it more carefully.



_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Mon Sep 25 12:34:56 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GRtO7-0002HW-Nx; Mon, 25 Sep 2006 12:32:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GRtO6-0002HR-JB
	for ipsec@ietf.org; Mon, 25 Sep 2006 12:32:58 -0400
Received: from iluvatar.zemris.fer.hr ([161.53.65.13])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRtO5-0000DT-7h
	for ipsec@ietf.org; Mon, 25 Sep 2006 12:32:58 -0400
Received: from localhost (unknown [127.0.0.1])
	by iluvatar.zemris.fer.hr (Postfix) with ESMTP id EC0FD13C005;
	Mon, 25 Sep 2006 16:28:50 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at zemris.fer.hr
Received: from iluvatar.zemris.fer.hr ([127.0.0.1])
	by localhost (iluvatar.zemris.fer.hr [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id OhR9xIykVmCg; Mon, 25 Sep 2006 18:28:49 +0200 (CEST)
Received: from Estella.zemris.fer.hr (Estella.zemris.fer.hr [161.53.65.43])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by iluvatar.zemris.fer.hr (Postfix) with ESMTP id 4A13413C003;
	Mon, 25 Sep 2006 18:28:49 +0200 (CEST)
From: Stjepan Gros <sgros@zemris.fer.hr>
To: ipsec@ietf.org
Content-Type: text/plain
Organization: FER - ZEMRIS
Date: Mon, 25 Sep 2006 18:32:51 +0200
Message-Id: <1159201971.11462.34.camel@estella.zemris.fer.hr>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: ikev2-devel@lists.sourceforge.net
Subject: [Ipsec] Address renewal...
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org

Hi!

We are adding DHCP support to IKEv2 daemon and we have one question
regarding renewal of leased IP addresses. Namely, when lease is about to
expire both initiator and responder know that, either via direct contact
to dhcp server (responder), or via cfg payload (initiator).

Now, there are two possibilities how to react:

1. Responder, without any request from initiator, tries to renew
address. Note that if responder succeeds in renewal (and gets the same
address), then it keeps SA further. Otherwise, if it doesn't succeed or
it got another IP address(es), then it deletes IKE SA.

2. Responder doesn't care and waits for Initiator to request, via CFG
payload, renewal. If initiator doesn't renew address (either doesn't try
or doesn't succeed), then, after some grace period, responder just
deletes IKE SA.

It seems like number 2 is more efficient, as far as resources are
concerned. Also, it seems like variant 1 can be emulated by variant 2
(tell initiator that lease is valid indefinitely, but responder does
renewal automatically).

So, what do you think is the correct behavior?

Thanks,
Stjepan


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Tue Sep 26 04:07:13 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GS7vx-0006Hp-ST; Tue, 26 Sep 2006 04:04:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GS7vw-0006Hk-NJ
	for ipsec@ietf.org; Tue, 26 Sep 2006 04:04:52 -0400
Received: from mgw-ext12.nokia.com ([131.228.20.171])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS7vv-0000DD-8M
	for ipsec@ietf.org; Tue, 26 Sep 2006 04:04:52 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145])
	by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id
	k8Q84jmp026974; Tue, 26 Sep 2006 11:04:50 +0300
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by
	esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 26 Sep 2006 11:04:49 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by
	esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 26 Sep 2006 11:04:49 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ipsec] Address renewal...
Date: Tue, 26 Sep 2006 11:04:48 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F24032BE139@esebe105.NOE.Nokia.com>
In-Reply-To: <1159201971.11462.34.camel@estella.zemris.fer.hr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ipsec] Address renewal...
Thread-Index: AcbgwcDrRRpSTdmtTsmJ4DkRGU4+vwAf6a8g
From: <Pasi.Eronen@nokia.com>
To: <sgros@zemris.fer.hr>, <ipsec@ietf.org>
X-OriginalArrivalTime: 26 Sep 2006 08:04:49.0101 (UTC)
	FILETIME=[7012CFD0:01C6E142]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: ikev2-devel@lists.sourceforge.net
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org


Hi,

In draft-eronen-ipsec-ikev2-clarifications (soon to appear as RFC),=20
we recommended not sending INTERNAL_ADDRESS_EXPIRY attributes at all.
This would imply option 1.

(The main reason being that the client shouldn't have to know or
care whether the address pool is managed by the gateway (responder)
itself, or some back-end server on behalf of the gateway. And=20
INTERNAL_ADDRESS_EXPIRY is not very useful in case it's managed
by the gateway itself.)

Best regards,
Pasi
=20
> -----Original Message-----
> From: ext Stjepan Gros [mailto:sgros@zemris.fer.hr]=20
> Sent: 25 September, 2006 19:33
> To: ipsec@ietf.org
> Cc: ikev2-devel@lists.sourceforge.net
> Subject: [Ipsec] Address renewal...
>=20
> Hi!
>=20
> We are adding DHCP support to IKEv2 daemon and we have one question
> regarding renewal of leased IP addresses. Namely, when lease=20
> is about to expire both initiator and responder know that, either=20
> via direct contact to dhcp server (responder), or via cfg payload=20
> (initiator).
>=20
> Now, there are two possibilities how to react:
>=20
> 1. Responder, without any request from initiator, tries to renew
> address. Note that if responder succeeds in renewal (and gets the same
> address), then it keeps SA further. Otherwise, if it doesn't=20
> succeed or it got another IP address(es), then it deletes IKE SA.
>=20
> 2. Responder doesn't care and waits for Initiator to request, via CFG
> payload, renewal. If initiator doesn't renew address (either=20
> doesn't try or doesn't succeed), then, after some grace=20
> period, responder just deletes IKE SA.
>=20
> It seems like number 2 is more efficient, as far as resources are
> concerned. Also, it seems like variant 1 can be emulated by variant 2
> (tell initiator that lease is valid indefinitely, but responder does
> renewal automatically).
>=20
> So, what do you think is the correct behavior?
>=20
> Thanks,
> Stjepan

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Tue Sep 26 06:56:19 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GSAZk-0006fU-8r; Tue, 26 Sep 2006 06:54:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GSAZO-0006Oh-EV
	for ipsec@ietf.org; Tue, 26 Sep 2006 06:53:46 -0400
Received: from web8802.mail.in.yahoo.com ([203.84.221.11])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GSAWK-00030H-3h
	for ipsec@ietf.org; Tue, 26 Sep 2006 06:50:37 -0400
Received: (qmail 91311 invoked by uid 60001); 26 Sep 2006 10:50:33 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in;
	h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=leMrAS7BwORCb+YDB4LWPjzrb2zVxSsEfRF/ppCkGs/qU+WLyEn9XrZmCYtYNYKbFJWQCAZyenR0VLyROMLlhvaFUSiviz1bOzgdzWcI3XZRzspKWRY76shX/Ie7qarS3bCrd9WOvcgiDhj4Wz+4R1V4pkcjfIYUNJykHOO/UuA=
	; 
Message-ID: <20060926105033.91309.qmail@web8802.mail.in.yahoo.com>
Received: from [124.30.5.98] by web8802.mail.in.yahoo.com via HTTP;
	Tue, 26 Sep 2006 11:50:33 BST
Date: Tue, 26 Sep 2006 11:50:33 +0100 (BST)
From: Pooja Kamra <poojakamra1981@yahoo.co.in>
Subject: RE: [Ipsec] Implementaton of AES-XCBC-MAC-96
To: Pasi.Eronen@nokia.com, ynir@checkpoint.com, ipsec@ietf.org
In-Reply-To: <B356D8F434D20B40A8CEDAEC305A1F24032BDDA9@esebe105.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: 3.2 (+++)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: 
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: poojakamra1981@yahoo.co.in
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org

Hi,

Thanks for clearing my doubt. I am still stuck at one
place. Can some one please help!!

Does anyone have step to step results of XCBC-MAC for
one of the published test vectors?

I have verified my implementation with other AES-XCBC
MAC implementations and it seems to be same.

But my tests seems to be failing. I am for now just
using test vector 3, i.e 

Test Case #3   : AES-XCBC-MAC-96 with 16-byte input
Key (K)        : 000102030405060708090a0b0c0d0e0f
Message (M)    : 000102030405060708090a0b0c0d0e0f
AES-XCBC-MAC   : d2a246fa349b68a79998a4394ff7a263
AES-XCBC-MAC-96: d2a246fa349b68a79998a439

my result seems to be unmatching with known.
Can any one provide me value of k1, k2, k3 please. 
Its going to be same for all the test vectors in The
RFC.

regards
Pooja

--- Pasi.Eronen@nokia.com wrote:

> Yoav Nir wrote:
> > > It's just a single "raw" AES encryption
> operation (I guess you
> > > could call it ECB in this context).
> > 
> > You still have to XOR the previous encrypted block
> from the message  
> > with the next plaintext block of the message, so
> it's not like ECB.   
> > It's like CBC.
> >
> > The best description is that it's CBC with an IV
> of zero.  E[0] here  
> > serves the same purpose as an IV in CBC.
> 
> That's true about the actual MAC calculation (steps
> 2..5), but
> the original question was about the K1/K2/K3
> calculation (step 1),
> where you don't XOR any previous blocks (and you
> have only
> a single block).
> 
> Best regards,
> Pasi
> 



		
___________________________________________________________ 
All New Yahoo! Mail – Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Wed Sep 27 04:19:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GSUbA-00044p-8G; Wed, 27 Sep 2006 04:16:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GSUb9-00044k-EP
	for ipsec@ietf.org; Wed, 27 Sep 2006 04:16:55 -0400
Received: from athena.kddi.com ([210.141.112.39] helo=UTMC1104.kddi.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSUb7-0000tO-0b
	for ipsec@ietf.org; Wed, 27 Sep 2006 04:16:55 -0400
Received: from usjk1037 (unknown [10.5.16.67])
	by UTMC1104.kddi.com (Postfix) with SMTP id 7F5421FCE
	for <ipsec@ietf.org>; Wed, 27 Sep 2006 17:16:38 +0900 (JST)
Received: from localhost (localhost [127.0.0.1])
	by localhost.kddi.com (Postfix) with SMTP id B0C951CAA
	for <ipsec@ietf.org>; Wed, 27 Sep 2006 17:16:37 +0900 (JST)
Received: from UTMC1111.kddi.com (unknown [10.5.16.5])
	by UTMC1124.kddi.com (Postfix) with ESMTP id 925EE1CAA;
	Wed, 27 Sep 2006 17:16:30 +0900 (JST)
Received: from [10.100.120.154] ([10.100.120.154] [10.100.120.154]) by
	post-ims.kddi.com with ESMTP; Wed, 27 Sep 2006 17:16:30 +0900
Message-Id: <451A335E.5070803@kddi.com>
Date: Wed, 27 Sep 2006 17:16:30 +0900
From: Kimihiro OHKI <ki-ohki@kddi.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: ipsec@ietf.org
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
X-WAuditID: 0609271716370000001204
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Subject: [Ipsec] Deleting IKE_SA and CHILD_SA
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org

Hi All,

Could you tell me the correct interpretation of IKEv2 specification
regarding following my basic question?

Precondition: There is a set of an IKE_SA and the corresponding
CHILD_SA pair between a node A and a node B.

Question: If the node A wants to normally delete the set of
connections (both the IKE_SA and CHILD_SA pair), is it enough for the
node A to send an INFORMATIONAL request which contains a DELETE
payload for the IKE_SA only (and then the node B responds via an empty
INFORMATIONAL response and both nodes implicitly and immediately close
the corresponding CHILD_SA pair), or does the node A need to send an
INFORMATIONAL request which contains 2 DELETE payloads (one for
IKE_SA, the other for CHILD_SA)?

Although I recognize Sec2.4 of rfc4306 says "Closing the IKE_SA
implicitly closes all associated CHILD_SAs.", it seems for me this
section does not mention normal termination case (active deletion) but
does just some cases such as timeout.

It seems sending DELETE payloads for both IKE_SA and CHILD_SA itself
does not violate the rfc, but I'd like to know whether it is:
(a) required or mandated behavior,
(b) recommended behavior, or
(c) some verbose behavior (not recommended),
and the rationale for the interpretation.

Another related consideration is, if the node B receive a DELETE
payload for the IKE_SA only, is the node B required whether:
(d) to close the corresponding CHILD_SA immediately (so the above (c)
is correct), or
(e) to wait some internal trigger to close the corresponding CHILD_SA
(so the above (c) causes unnecessary remained resources and (a) or (b)
is correct)?

Best Regards,
Kimihiro Ohki


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Wed Sep 27 04:48:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GSV4N-0004L1-QQ; Wed, 27 Sep 2006 04:47:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GSV4M-0004Kv-Ge
	for ipsec@ietf.org; Wed, 27 Sep 2006 04:47:06 -0400
Received: from michael.checkpoint.com ([194.29.32.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSV4K-0007rb-Uc
	for ipsec@ietf.org; Wed, 27 Sep 2006 04:47:06 -0400
Received: from [194.29.46.218] (localhost [127.0.0.1])
	by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id
	k8R8kkKP029349; Wed, 27 Sep 2006 11:46:46 +0300 (IDT)
In-Reply-To: <451A335E.5070803@kddi.com>
References: <451A335E.5070803@kddi.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <70DFCB91-A1C4-4197-AC7C-4E83BCAD0046@checkpoint.com>
Content-Transfer-Encoding: 7bit
From: Yoav Nir <ynir@checkpoint.com>
Subject: Re: [Ipsec] Deleting IKE_SA and CHILD_SA
Date: Wed, 27 Sep 2006 11:46:38 +0300
To: Kimihiro OHKI <ki-ohki@kddi.com>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: ipsec@ietf.org
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org

My comments inline

On Sep 27, 2006, at 11:16 AM, Kimihiro OHKI wrote:

> Hi All,
>
> Could you tell me the correct interpretation of IKEv2 specification
> regarding following my basic question?
>
> Precondition: There is a set of an IKE_SA and the corresponding
> CHILD_SA pair between a node A and a node B.

This is a special case.  There could be many child SA pairs.

>
> Question: If the node A wants to normally delete the set of
> connections (both the IKE_SA and CHILD_SA pair), is it enough for the
> node A to send an INFORMATIONAL request which contains a DELETE
> payload for the IKE_SA only (and then the node B responds via an empty
> INFORMATIONAL response and both nodes implicitly and immediately close
> the corresponding CHILD_SA pair), or does the node A need to send an
> INFORMATIONAL request which contains 2 DELETE payloads (one for
> IKE_SA, the other for CHILD_SA)?

You can send more than 1 DELETE payloads, but since sending the IKE  
SA delete alone accomplishes the same goal, the others are redundant.

>
> Although I recognize Sec2.4 of rfc4306 says "Closing the IKE_SA
> implicitly closes all associated CHILD_SAs.", it seems for me this
> section does not mention normal termination case (active deletion) but
> does just some cases such as timeout.

It mentions timeouts because its focus is on site2site connections  
where it is not "normal" to terminate tunnels.  A "disconnect" event  
is normal for remote access, but deleting the IKE SA accomplishes the  
same thing.

> It seems sending DELETE payloads for both IKE_SA and CHILD_SA itself
> does not violate the rfc, but I'd like to know whether it is:
> (a) required or mandated behavior,
> (b) recommended behavior, or
> (c) some verbose behavior (not recommended),
> and the rationale for the interpretation.

I'd go with (c).  An RFC-compliant implementation should still work  
if you send multiple DELETE payloads, but it's just not needed.   
Sending one DELETE payload sends the message that you don't want to  
talk to the peer any more on any of the established SAs.  Note that  
what you're suggesting is sending a DELETE for all ESP and AH SAs  
that you have.  Seems wasteful.

>
> Another related consideration is, if the node B receive a DELETE
> payload for the IKE_SA only, is the node B required whether:
> (d) to close the corresponding CHILD_SA immediately (so the above (c)
> is correct), or
> (e) to wait some internal trigger to close the corresponding CHILD_SA
> (so the above (c) causes unnecessary remained resources and (a) or (b)
> is correct)?

Like it says in section 2.4: "Closing the IKE_SA implicitly closes  
all associated CHILD_SAs."  So (d) is correct.  This really is the  
cleanest way to "disconnect"

Besides, deleting the IKE SA is equivalent to revoking the  
authorization, so you shouldn't accept or send traffic without  
authorization.

>
> Best Regards,
> Kimihiro Ohki


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Wed Sep 27 05:36:32 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GSVow-00049d-3A; Wed, 27 Sep 2006 05:35:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GSVou-00048s-Fv
	for ipsec@ietf.org; Wed, 27 Sep 2006 05:35:12 -0400
Received: from athena.kddi.com ([210.141.112.39] helo=UTMC1102.kddi.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSVir-0000Nm-Ej
	for ipsec@ietf.org; Wed, 27 Sep 2006 05:28:59 -0400
Received: from usjk1037 (unknown [10.5.16.67])
	by UTMC1102.kddi.com (Postfix) with SMTP id 4184B21C3;
	Wed, 27 Sep 2006 18:28:53 +0900 (JST)
Received: from localhost (localhost [127.0.0.1])
	by localhost.kddi.com (Postfix) with SMTP id 5B1441A20;
	Wed, 27 Sep 2006 18:28:47 +0900 (JST)
Received: from UTMC1111.kddi.com (unknown [10.5.16.5])
	by UTMC1124.kddi.com (Postfix) with ESMTP id A64351A20;
	Wed, 27 Sep 2006 18:28:44 +0900 (JST)
Received: from [10.100.120.154] ([10.100.120.154] [10.100.120.154]) by
	post-ims.kddi.com with ESMTP; Wed, 27 Sep 2006 18:28:44 +0900
Message-Id: <451A444C.8080203@kddi.com>
Date: Wed, 27 Sep 2006 18:28:44 +0900
From: Kimihiro OHKI <ki-ohki@kddi.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>
Subject: Re: [Ipsec] Deleting IKE_SA and CHILD_SA
References: <451A335E.5070803@kddi.com>
	<70DFCB91-A1C4-4197-AC7C-4E83BCAD0046@checkpoint.com>
In-Reply-To: <70DFCB91-A1C4-4197-AC7C-4E83BCAD0046@checkpoint.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-WAuditID: 0609271828470000012575
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: ipsec@ietf.org
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org

Thank you for your quick reply and detailed comment.
As you may know, 3GPP and 3GPP2 are making standards for remote VPN 
access which refer this rfc. So IKE_SA creating only one CHILD_SA pair 
and the "disconnect" event are not special in such environment.
Anyway, it becomes clear for me.

Best Regards,
Kimihiro Ohki

> My comments inline
> 
> On Sep 27, 2006, at 11:16 AM, Kimihiro OHKI wrote:
> 
>> Hi All,
>>
>> Could you tell me the correct interpretation of IKEv2 specification
>> regarding following my basic question?
>>
>> Precondition: There is a set of an IKE_SA and the corresponding
>> CHILD_SA pair between a node A and a node B.
> 
> This is a special case.  There could be many child SA pairs.
> 
>>
>> Question: If the node A wants to normally delete the set of
>> connections (both the IKE_SA and CHILD_SA pair), is it enough for the
>> node A to send an INFORMATIONAL request which contains a DELETE
>> payload for the IKE_SA only (and then the node B responds via an empty
>> INFORMATIONAL response and both nodes implicitly and immediately close
>> the corresponding CHILD_SA pair), or does the node A need to send an
>> INFORMATIONAL request which contains 2 DELETE payloads (one for
>> IKE_SA, the other for CHILD_SA)?
> 
> You can send more than 1 DELETE payloads, but since sending the IKE SA 
> delete alone accomplishes the same goal, the others are redundant.
> 
>>
>> Although I recognize Sec2.4 of rfc4306 says "Closing the IKE_SA
>> implicitly closes all associated CHILD_SAs.", it seems for me this
>> section does not mention normal termination case (active deletion) but
>> does just some cases such as timeout.
> 
> It mentions timeouts because its focus is on site2site connections where 
> it is not "normal" to terminate tunnels.  A "disconnect" event is normal 
> for remote access, but deleting the IKE SA accomplishes the same thing.
> 
>> It seems sending DELETE payloads for both IKE_SA and CHILD_SA itself
>> does not violate the rfc, but I'd like to know whether it is:
>> (a) required or mandated behavior,
>> (b) recommended behavior, or
>> (c) some verbose behavior (not recommended),
>> and the rationale for the interpretation.
> 
> I'd go with (c).  An RFC-compliant implementation should still work if 
> you send multiple DELETE payloads, but it's just not needed.  Sending 
> one DELETE payload sends the message that you don't want to talk to the 
> peer any more on any of the established SAs.  Note that what you're 
> suggesting is sending a DELETE for all ESP and AH SAs that you have.  
> Seems wasteful.
> 
>>
>> Another related consideration is, if the node B receive a DELETE
>> payload for the IKE_SA only, is the node B required whether:
>> (d) to close the corresponding CHILD_SA immediately (so the above (c)
>> is correct), or
>> (e) to wait some internal trigger to close the corresponding CHILD_SA
>> (so the above (c) causes unnecessary remained resources and (a) or (b)
>> is correct)?
> 
> Like it says in section 2.4: "Closing the IKE_SA implicitly closes all 
> associated CHILD_SAs."  So (d) is correct.  This really is the cleanest 
> way to "disconnect"
> 
> Besides, deleting the IKE SA is equivalent to revoking the 
> authorization, so you shouldn't accept or send traffic without 
> authorization.
> 
>>
>> Best Regards,
>> Kimihiro Ohki
> 



_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Fri Sep 29 12:40:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GTLKb-0005hI-Iv; Fri, 29 Sep 2006 12:35:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GTLKa-0005eL-3v
	for ipsec@ietf.org; Fri, 29 Sep 2006 12:35:20 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTL8O-00040K-2K
	for ipsec@ietf.org; Fri, 29 Sep 2006 12:22:47 -0400
Received: from [10.20.30.177] (dsl-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8TGMeFW060746
	for <ipsec@ietf.org>; Fri, 29 Sep 2006 09:22:41 -0700 (MST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p0623099ac142f8a9e14a@[10.20.30.177]>
Date: Fri, 29 Sep 2006 09:22:17 -0700
To: IPsec WG <ipsec@ietf.org>
From: Internet-Drafts@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Subject: [Ipsec] I-D ACTION:draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Robust Header Compression Working 
Group of the IETF.

	Title		: Extensions to IKEv2 to Support Header 
Compression over IPsec (HCoIPsec)
	Author(s)	: R. Jasani, et al.
	Filename	: draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt
	Pages		: 15
	Date		: 2006-9-29

When using Header Compression (HC) schemes in conjunction with IPsec
(i.e., [HCOIPSEC]) a mechanism is needed to negotiate both the HC
scheme and any associated configuration parameters between end-points
prior to operation.  Internet Key Exchange (IKE) is a mechanism which
can be leveraged to handle these negotiations.  This document
specifies extensions to Internet Key Exchange (IKEv2) that will allow
header compression schemes and their associated configuration
parameters to be negotiated for IPsec security associations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE 
/internet-drafts/draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which From ipsec-bounces@ietf.org Fri Sep 29 12:40:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GTLKb-0005hI-Iv; Fri, 29 Sep 2006 12:35:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GTLKa-0005eL-3v
	for ipsec@ietf.org; Fri, 29 Sep 2006 12:35:20 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTL8O-00040K-2K
	for ipsec@ietf.org; Fri, 29 Sep 2006 12:22:47 -0400
Received: from [10.20.30.177] (dsl-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8TGMeFW060746
	for <ipsec@ietf.org>; Fri, 29 Sep 2006 09:22:41 -0700 (MST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p0623099ac142f8a9e14a@[10.20.30.177]>
Date: Fri, 29 Sep 2006 09:22:17 -0700
To: IPsec WG <ipsec@ietf.org>
From: Internet-Drafts@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Subject: [Ipsec] I-D ACTION:draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Robust Header Compression Working 
Group of the IETF.

	Title		: Extensions to IKEv2 to Support Header 
Compression over IPsec (HCoIPsec)
	Author(s)	: R. Jasani, et al.
	Filename	: draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt
	Pages		: 15
	Date		: 2006-9-29

When using Header Compression (HC) schemes in conjunction with IPsec
(i.e., [HCOIPSEC]) a mechanism is needed to negotiate both the HC
scheme and any associated configuration parameters between end-points
prior to operation.  Internet Key Exchange (IKE) is a mechanism which
can be leveraged to handle these negotiations.  This document
specifies extensions to Internet Key Exchange (IKEv2) that will allow
header compression schemes and their associated configuration
parameters to be negotiated for IPsec security associations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE 
/internet-drafts/draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


[The following attachment must be fetched by mail. Command-click the 
URL below and send the resulting message to get the attachment.]
<mailto:mailserv@ietf.org?body=ENCODING%20mime%0D%0AFILE%20/internet-drafts/draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt>
[The following attachment must be fetched by ftp.  Command-click the 
URL below to ask your ftp client to fetch it.]
<ftp://ftp.ietf.org/internet-drafts/draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt>
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec

From ipsec-bounces@ietf.org Fri Sep 29 12:40:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GTLKc-0005hO-7q; Fri, 29 Sep 2006 12:35:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GTLKa-0005Tp-4H
	for ipsec@ietf.org; Fri, 29 Sep 2006 12:35:20 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTL8O-00040N-2H
	for ipsec@ietf.org; Fri, 29 Sep 2006 12:22:47 -0400
Received: from [10.20.30.177] (dsl-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8TGMeFY060746
	for <ipsec@ietf.org>; Fri, 29 Sep 2006 09:22:41 -0700 (MST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p0623099bc142f8c2e71d@[10.20.30.177]>
Date: Fri, 29 Sep 2006 09:22:37 -0700
To: IPsec WG <ipsec@ietf.org>
From: Internet-Drafts@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Subject: [Ipsec] I-D ACTION:draft-kelly-ipsec-ciph-sha2-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: Using HMAC-SHA-256 With IPsec
	Author(s)	: S. Kelly, S. Frankel
	Filename	: draft-kelly-ipsec-ciph-sha2-00.txt
	Pages		: 14
	Date		: 2006-9-29


    This specification describes the use of the SHA-256 algorithm in
    conjunction with HMAC as a data origin authentication and integrity
    verification mechanism for the IPsec AH, ESP, and IKEv2 protocols,
    and also as a PRF for IKEv2.  Two output truncation lengths are
    specified for data origin authentication and integrity verification
    usage, with the corresponding algorithms designated as HMAC-SHA-256-
    128 and HMAC-SHA-256-192.  No truncation is specified for PRF usage,
    and the resulting algorithm is designated as HMAC-SHA-PRF-256.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kelly-ipsec-ciph-sha2-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-kelly-ipsec-ciph-sha2-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtwill enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


[The following attachment must be fetched by mail. Command-click the 
URL below and send the resulting message to get the attachment.]
<mailto:mailserv@ietf.org?body=ENCODING%20mime%0D%0AFILE%20/internet-drafts/draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt>
[The following attachment must be fetched by ftp.  Command-click the 
URL below to ask your ftp client to fetch it.]
<ftp://ftp.ietf.org/internet-drafts/draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt>
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec

From ipsec-bounces@ietf.org Fri Sep 29 12:40:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GTLKc-0005hO-7q; Fri, 29 Sep 2006 12:35:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GTLKa-0005Tp-4H
	for ipsec@ietf.org; Fri, 29 Sep 2006 12:35:20 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTL8O-00040N-2H
	for ipsec@ietf.org; Fri, 29 Sep 2006 12:22:47 -0400
Received: from [10.20.30.177] (dsl-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k8TGMeFY060746
	for <ipsec@ietf.org>; Fri, 29 Sep 2006 09:22:41 -0700 (MST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p0623099bc142f8c2e71d@[10.20.30.177]>
Date: Fri, 29 Sep 2006 09:22:37 -0700
To: IPsec WG <ipsec@ietf.org>
From: Internet-Drafts@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Subject: [Ipsec] I-D ACTION:draft-kelly-ipsec-ciph-sha2-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: Using HMAC-SHA-256 With IPsec
	Author(s)	: S. Kelly, S. Frankel
	Filename	: draft-kelly-ipsec-ciph-sha2-00.txt
	Pages		: 14
	Date		: 2006-9-29


    This specification describes the use of the SHA-256 algorithm in
    conjunction with HMAC as a data origin authentication and integrity
    verification mechanism for the IPsec AH, ESP, and IKEv2 protocols,
    and also as a PRF for IKEv2.  Two output truncation lengths are
    specified for data origin authentication and integrity verification
    usage, with the corresponding algorithms designated as HMAC-SHA-256-
    128 and HMAC-SHA-256-192.  No truncation is specified for PRF usage,
    and the resulting algorithm is designated as HMAC-SHA-PRF-256.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kelly-ipsec-ciph-sha2-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-kelly-ipsec-ciph-sha2-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-kelly-ipsec-ciph-sha2-00.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


[The following attachment must be fetched by mail. Command-click the 
URL below and send the resulting message to get the attachment.]
<mailto:mailserv@ietf.org?body=ENCODING%20mime%0D%0AFILE%20/internet-drafts/draft-kelly-ipsec-ciph-sha2-00.txt>
[The following attachment must be fetched by ftp.  Command-click the 
URL below to ask your ftp client to fetch it.]
<ftp://ftp.ietf.org/internet-drafts/draft-kelly-ipsec-ciph-sha2-00.txt>
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec





ained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-kelly-ipsec-ciph-sha2-00.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


[The following attachment must be fetched by mail. Command-click the 
URL below and send the resulting message to get the attachment.]
<mailto:mailserv@ietf.org?body=ENCODING%20mime%0D%0AFILE%20/internet-drafts/draft-kelly-ipsec-ciph-sha2-00.txt>
[The following attachment must be fetched by ftp.  Command-click the 
URL below to ask your ftp client to fetch it.]
<ftp://ftp.ietf.org/internet-drafts/draft-kelly-ipsec-ciph-sha2-00.txt>
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec





From ipsec-bounces@ietf.org Fri Sep 29 13:03:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GTLjt-00078W-Kv; Fri, 29 Sep 2006 13:01:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GTLjs-00078R-GL
	for ipsec@ietf.org; Fri, 29 Sep 2006 13:01:28 -0400
Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTLjq-0002ow-WD
	for ipsec@ietf.org; Fri, 29 Sep 2006 13:01:28 -0400
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com;
	b=TLxqVFGgVpt2Mm0fkwsqiQdZesxayEm1S3pamX1FIOBvnF9xzFUnXjiV20vGAOT3;
	h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.53] (helo=elwamui-wigeon.atl.sa.earthlink.net)
	by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34)
	id 1GTLjo-0006f1-JG
	for ipsec@ietf.org; Fri, 29 Sep 2006 13:01:24 -0400
Received: from 75.32.19.206 by webmail.pas.earthlink.net with HTTP;
	Fri, 29 Sep 2006 13:01:24 -0400
Message-ID: <13001419.1159549284566.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net>
Date: Fri, 29 Sep 2006 13:01:24 -0400 (EDT)
From: "Scott G. Kelly" <s.kelly@ix.netcom.com>
To: ipsec list <ipsec@ietf.org>
Subject: Fw: [Ipsec] I-D ACTION:draft-kelly-ipsec-ciph-sha2-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff710fe0f8a6147b05741df1f57aefbe581c6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.53
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Scott G. Kelly" <scott@hyperthought.com>
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org

Please review and comment on this draft. It's a revamped version of draft-ietf-ipsec-ciph-sha2-01.txt, resurrected at Russ's request.  

-----Forwarded Message-----
>From: Internet-Drafts@ietf.org
>Sent: Sep 29, 2006 12:22 PM
>To: IPsec WG <ipsec@ietf.org>
>Subject: [Ipsec] I-D ACTION:draft-kelly-ipsec-ciph-sha2-00.txt
>
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
>	Title		: Using HMAC-SHA-256 With IPsec
>	Author(s)	: S. Kelly, S. Frankel
>	Filename	: draft-kelly-ipsec-ciph-sha2-00.txt
>	Pages		: 14
>	Date		: 2006-9-29
>
>
>    This specification describes the use of the SHA-256 algorithm in
>    conjunction with HMAC as a data origin authentication and integrity
>    verification mechanism for the IPsec AH, ESP, and IKEv2 protocols,
>    and also as a PRF for IKEv2.  Two output truncation lengths are
>    specified for data origin authentication and integrity verification
>    usage, with the corresponding algorithms designated as HMAC-SHA-256-
>    128 and HMAC-SHA-256-192.  No truncation is specified for PRF usage,
>    and the resulting algorithm is designated as HMAC-SHA-PRF-256.
>
>
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-kelly-ipsec-ciph-sha2-00.txt
>
>To remove yourself from the I-D Announcement list, send a message to
>i-d-announce-request@ietf.org with the word unsubscribe in the body of
>the message.
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>to change your subscription settings.
>
>Internet-Drafts are also available by anonymous FTP. Login with the
>username "anonymous" and a password of your e-mail address. After
>logging in, type "cd internet-drafts" and then
>"get draft-kelly-ipsec-ciph-sha2-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	mailserv@ietf.org.
>In the body type:
>	"FILE /internet-drafts/draft-kelly-ipsec-ciph-sha2-00.txt".
>
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>
>[The following attachment must be fetched by mail. Command-click the 
>URL below and send the resulting message to get the attachment.]
><mailto:mailserv@ietf.org?body=ENCODING%20mime%0D%0AFILE%20/internet-drafts/draft-kelly-ipsec-ciph-sha2-00.txt>
>[The following attachment must be fetched by ftp.  Command-click the 
>URL below to ask your ftp client to fetch it.]
><ftp://ftp.ietf.org/internet-drafts/draft-kelly-ipsec-ciph-sha2-00.txt>
>_______________________________________________
>I-D-Announce mailing list
>I-D-Announce@ietf.org
>https://www1.ietf.org/mailman/listinfo/i-d-announce
>
>_______________________________________________
>Ipsec mailing list
>Ipsec@ietf.org
>https://www1.ietf.org/mailman/listinfo/ipsec


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Fri Sep 29 14:50:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GTNO7-00084H-FI; Fri, 29 Sep 2006 14:47:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GTNO5-00081h-G3
	for ipsec@ietf.org; Fri, 29 Sep 2006 14:47:05 -0400
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTNO2-0005pz-2L
	for ipsec@ietf.org; Fri, 29 Sep 2006 14:47:05 -0400
Received: from eastmail2bur.East.Sun.COM ([129.148.13.40])
	by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id
	k8TIl09c002994; Fri, 29 Sep 2006 11:47:00 -0700 (PDT)
Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66])
	by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with
	ESMTP id k8TIkxIO025171; Fri, 29 Sep 2006 14:46:59 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by thunk.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k8TIkxwA019744; 
	Fri, 29 Sep 2006 14:46:59 -0400 (EDT)
From: Bill Sommerfeld <sommerfeld@sun.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
In-Reply-To: <tslpsdecyk2.fsf@cz.mit.edu>
References: <tslpsdecyk2.fsf@cz.mit.edu>
Content-Type: text/plain
Date: Fri, 29 Sep 2006 14:46:59 -0400
Message-Id: <1159555619.16677.89.camel@thunk>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.2 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: saag@mit.edu, ipsec@ietf.org, tsvwg-chairs@tools.ietf.org
Subject: [Ipsec] Re: [saag] tsvwg,
	preemption and rsvp: exposing characteristics of
	confidential traffic
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org

On Fri, 2006-09-29 at 14:33 -0400, Sam Hartman wrote:
> These drafts set up a model under which each precedence class of data
> from a preemption standpoint goes over its own SA and uses its own
> aggregate RSVP reservation.  What that means is you expose on the
> unprotected side of the interface what fraction of your traffic is at
> each precedence level.
> 
> First question: Is this new or something we have signed onto in the
> past?

it's something we've signed on to in the past in the context of
diffserv; the architecture is such that the actual
preemption/priority/etc mechanism is almost completely opaque to IPsec.

See rfc4301, halfway into section 4.1 (starting near the bottom of page
13):

   If different classes of traffic (distinguished by Differentiated
   Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on
   the same SA, and if the receiver is employing the optional
   anti-replay feature available in both AH and ESP, this could result
   in inappropriate discarding of lower priority packets due to the
   windowing mechanism used by this feature.  Therefore, a sender SHOULD
   put traffic of different classes, but with the same selector values,
   on different SAs to support Quality of Service (QoS) appropriately.
   To permit this, the IPsec implementation MUST permit establishment
   and maintenance of multiple SAs between a given sender and receiver,
   with the same selectors.  Distribution of traffic among these
   parallel SAs to support QoS is locally determined by the sender and
   is not negotiated by IKE.  The receiver MUST process the packets from
   the different SAs without prejudice.  These requirements apply to
   both transport and tunnel mode SAs.  In the case of tunnel mode SAs,
   the DSCP values in question appear in the inner IP header.  In
   transport mode, the DSCP value might change en route, but this should
   not cause problems with respect to IPsec processing since the value
   is not employed for SA selection and MUST NOT be checked as part of
   SA/packet validation.  However, if significant re-ordering of packets
   occurs in an SA, e.g., as a result of changes to DSCP values en
   route, this may trigger packet discarding by a receiver due to
   application of the anti-replay mechanism.

seems obvious to extend this to rsvp or any other scheme which involves
intentional packet reordering by the network.



_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Fri Sep 29 16:31:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GTOxs-00061z-Vm; Fri, 29 Sep 2006 16:28:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GTOxs-00061u-Hf
	for ipsec@ietf.org; Fri, 29 Sep 2006 16:28:08 -0400
Received: from machshav.com ([147.28.0.16])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTOxr-0006Gz-69
	for ipsec@ietf.org; Fri, 29 Sep 2006 16:28:08 -0400
Received: by machshav.com (Postfix, from userid 512)
	id 29059FB2BE; Fri, 29 Sep 2006 16:27:52 -0400 (EDT)
Received: from berkshire.machshav.com (localhost [127.0.0.1])
	by machshav.com (Postfix) with ESMTP id 1467CFB2AD;
	Fri, 29 Sep 2006 16:27:51 -0400 (EDT)
Received: by berkshire.machshav.com (Postfix, from userid 54047)
	id 0010F3C07A0; Fri, 29 Sep 2006 16:27:53 -0400 (EDT)
Date: Fri, 29 Sep 2006 16:27:53 -0400
From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: "Scott G. Kelly" <scott@hyperthought.com>
Subject: Re: Fw: [Ipsec] I-D ACTION:draft-kelly-ipsec-ciph-sha2-00.txt
Message-Id: <20060929162753.b39eac78.smb@cs.columbia.edu>
In-Reply-To: <13001419.1159549284566.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net>
References: <13001419.1159549284566.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net>
Organization: Columbia University
X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; i386--netbsdelf)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: ipsec list <ipsec@ietf.org>, "Scott G. Kelly" <s.kelly@ix.netcom.com>
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org

On Fri, 29 Sep 2006 13:01:24 -0400 (EDT), "Scott G. Kelly"
<s.kelly@ix.netcom.com> wrote:

> Please review and comment on this draft. It's a revamped version of
> draft-ietf-ipsec-ciph-sha2-01.txt, resurrected at Russ's request.  


I found 2.1.1 + 2.1.2 confusing.  2.1.1 says you can't have keys of other
than length 256.  I might quarrel with that -- I'd definitely have used
SHOULD NOT instead of MUST NOT -- but 2.1.2 tells you what to do if your
key isn't 256 bits long.  I perceive no increase in security from padding
a short key with zeros, nor do I understand why it's better to do a
SHA-256 reduction on a long key before using it with HMAC rather than
simply using the longer key directly.  And the notion of a variable key
length function where the variable is constrained to exactly one value is
a bit strange.

You might want to cite RFC 4634 as an Informative reference, since it has
code, and 4231 since it also gives definitions and code points for other
uses of HMAC-SHA-256.

Stepping back a bit, I personally would rather see a single RFC describing
how to use a number of different hash functions with HMAC.  I could almost
use a set of text editor substitution patterns to change this draft from
SHA-256 to SHA-384 or SHA-512.  The core of such a document would be a
table listing acceptable key sizes and truncation sizes for each function
considered.  An appendix could list test vectors.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Fri Sep 29 17:24:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GTPoP-0004oH-UH; Fri, 29 Sep 2006 17:22:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GTPoO-0004oC-D5
	for ipsec@ietf.org; Fri, 29 Sep 2006 17:22:24 -0400
Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTPoM-0006dI-F8
	for ipsec@ietf.org; Fri, 29 Sep 2006 17:22:23 -0400
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com;
	b=hbLzbBWbUjnQuQ9wgv04f4o5YE/RfBSrZ28fa/s1isTRWNRNbflzKB0OgRrLLIIB;
	h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.53] (helo=elwamui-wigeon.atl.sa.earthlink.net)
	by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34)
	id 1GTPoB-0008Ie-R5; Fri, 29 Sep 2006 17:22:11 -0400
Received: from 75.32.19.206 by webmail.pas.earthlink.net with HTTP;
	Fri, 29 Sep 2006 17:22:11 -0400
Message-ID: <31324918.1159564931917.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net>
Date: Fri, 29 Sep 2006 17:22:11 -0400 (EDT)
From: "Scott G. Kelly" <s.kelly@ix.netcom.com>
To: "Steven M. Bellovin" <smb@cs.columbia.edu>
Subject: Re: Fw: [Ipsec] I-D ACTION:draft-kelly-ipsec-ciph-sha2-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 5b98cdd91c374dcd776432462e451d7bd15d05d9470ff7101e722121a44b6f920ac8d04312deb141350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.53
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: ipsec list <ipsec@ietf.org>
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Scott G. Kelly" <scott@hyperthought.com>
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org

Hi Steve,

Thanks for the quick and detailed review.  Responses inline...

>I found 2.1.1 + 2.1.2 confusing.  2.1.1 says you can't have keys of other
>than length 256.  I might quarrel with that -- I'd definitely have used
>SHOULD NOT instead of MUST NOT -- but 2.1.2 tells you what to do if your
>key isn't 256 bits long.  I perceive no increase in security from padding
>a short key with zeros, nor do I understand why it's better to do a
>SHA-256 reduction on a long key before using it with HMAC rather than
>simply using the longer key directly.  And the notion of a variable key
>length function where the variable is constrained to exactly one value is
>a bit strange.

Part of the confusion probably derives from trying to combine PRF functionality into the same doc with authentication/integrity functionality (the latter of which was already in the doc), yet maintain differing requirements for the keys. Maybe that was a mistake. The intent was that for integrity/auth, you have to use a fixed length, as RFC2104 explicitly recommends against shorter keys, and this lanuage is consistent with RFC2403 and the other HMAC RFCs.

We added the PRF support after that text was written (rather than writing a separate doc), and in the interest of flexibility, chose to allow variable length keys.  I'm wondering now if that was a mistake, and we should have had a single position on key sizes. That would definitely simplify things.

As for padding short keys, it certainly adds no security. It is there to explicitly tell implementors what to do (so they don't instead hash the key, and use the output). It's called out for the sake of interoperability. 

As for using longer keys, I see now that I misread this line in 2104:

"Applications that use keys longer than B bytes will first hash the key using H and then use the resultant L byte string as the actual key to HMAC."

'B' refers to the block size (in this case, 512 bits), but I was thinking of 256 bits, in which case you would simply hash the key and use the output. Definitely my mistake, and I will fix this in the next rev.

>You might want to cite RFC 4634 as an Informative reference, since it has
>code, and 4231 since it also gives definitions and code points for other
>uses of HMAC-SHA-256.

Okay.

>Stepping back a bit, I personally would rather see a single RFC describing
>how to use a number of different hash functions with HMAC.  I could almost
>use a set of text editor substitution patterns to change this draft from
>SHA-256 to SHA-384 or SHA-512.  The core of such a document would be a
>table listing acceptable key sizes and truncation sizes for each function
>considered.  An appendix could list test vectors.

Russ just mentioned that NSA-B requires SHA-384 support, and I was looking at the draft to see if that could be cleanly dropped in - this might be one way to do it.  If there is general support for this approach, we can look at what it would take to re-spin the doc.

Thanks again for the review,

Scott



_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Fri Sep 29 18:22:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GTQie-0004ja-GM; Fri, 29 Sep 2006 18:20:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GTQid-0004jU-36
	for ipsec@ietf.org; Fri, 29 Sep 2006 18:20:31 -0400
Received: from mexforward.lss.emc.com ([128.222.32.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTQib-0001Fp-N6
	for ipsec@ietf.org; Fri, 29 Sep 2006 18:20:31 -0400
Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14])
	by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k8TMKOVO006746; Fri, 29 Sep 2006 18:20:24 -0400 (EDT)
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com
	[10.254.64.53])
	by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k8TMKJMk012889; Fri, 29 Sep 2006 18:20:20 -0400 (EDT)
From: Black_David@emc.com
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Fri, 29 Sep 2006 18:01:23 -0400
Message-ID: <F222151D3323874393F83102D614E05502B67459@CORPUSMX20A.corp.emc.com>
In-Reply-To: <tslpsdecyk2.fsf@cz.mit.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [saag] tsvwg, preemption and rsvp: exposing characteristics of
	confidentialtraffic
thread-index: Acbj9mol+vmyK8cHTnSbIyQ6vL4/PAAE7wFQ
To: <hartmans-ietf@MIT.EDU>, <saag@MIT.EDU>, <ipsec@ietf.org>
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935,
	Antispam-Data: 2006.9.29.145442
X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2,
	NO_REAL_NAME 0, __C230066_P5 0, __CP_NOT_1 0, __CP_URI_IN_BODY 0,
	__CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0,
	__HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0,
	__MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21
Cc: tsvwg-chairs@tools.ietf.org, flefauch@cisco.com, fred@cisco.com
Subject: [Ipsec] RE: [saag] tsvwg,
	preemption and rsvp: exposing characteristics of confidentialtraffic
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org

Sam,

The terminology in this space is confusing, and used in different
ways in different documents, so let's stick to this clarification
from Section 1 of the VPN Signaled Preemption draft:

   For the purposes of the
   present discussion, "priority" is a set of algorithms applied to
   datagrams, where "precedence" is a policy attribute of sessions.

In other words, "priority" is about traffic handling (e.g., Diffserv)
whereas "precedence" is about admission control.  Despite this, the
VPN Signaled Preemption draft then proceeds to use "Priority" (NB:
first letter capitalized) for things that are actually "precedence".
For example, in Section 1.3:

   Preemption of a reservation is specified in the context,
   in [RFC3181] which in essence specifies that a reservation installed
   in the network using an Preemption Priority and retained using a
   separate Defending Priority may be removed by the network via an RESV
   Error signal that removes the entire reservation.

That's an unfortunate source of confusion.  I would strongly encourage
the authors to clean this up, particularly their unfortunate use of
'"priority"' as a precedence level in Sections 2.3.3 and 2.3.4 (example
quoted below in this message).

In order to avoid further confusion, I will use the phrase "Diffserv
priority" to refer to priority for datagram traffic handling.

Nonetheless, on your concern:

> These drafts set up a model under which each precedence class of data
> from a preemption standpoint goes over its own SA and uses its own
> aggregate RSVP reservation.  What that means is you expose on the
> unprotected side of the interface what fraction of your traffic is at
> each precedence level.

Actually, only the vpn-signaled-preemption draft appears to do this.

The rsvp-ipsec draft allows multiple reservations between the same
endpoints for the same DSCP, which would allow such traffic to use
different tunnels but if it requires traffic for different
reservations to use different tunnels, I was not able to find
a statement of that requirement.

OTOH, the vpn-signaled-preemption draft is quite clear that different
precedence levels for the same DSCP result in different IPsec tunnels.
Section 2.3.3 says:

   Due to
   the mechanics of preemption, however, this would not expand the
   existing "routine" reservations in the interface and inner domains,
   as doing this causes loss of information - how much of the
   reservation is now "routine" and how much is "priority"?  Rather,
   this new reservation will open up a separate set of tunnels or
   security associations for traffic of its application class at its
   precedence between that aggregator and deaggregator.

Here, "priority" is being used in its "Priority" sense as a level of
precedence.  The concern I have here is that the second sentence quoted
above does not immediately follow from the first - there's a missing
logical step in asserting that if the aggregate traffic for a DSCP
(single Diffserv priority level) exceeds the reserved and/or available
capacity then the policing of that traffic to the appropriate limit
MUST respect precedence (i.e., delay/drop/shape "routine" traffic before
"priority" traffic).  That requirement should be asserted and defended
in the vpn-signaled-preemption draft, because it is what leads to
your concern.  Meeting that requirement in general requires segregation
of traffic at each precedence level within a single Diffserv priority,
and because the reservation identity is not marked on the datagrams,
separate IPsec tunnels are needed to do this, thus making precedence
distinctions within a Diffserv priority visible to traffic analysis
between the VPN routers.

At least, that's what I think is going on (the confusing use of the
'priority' word doesn't help).  I've added Fred Baker and Francois
LeFaucheur to the cc: line so that they can correct anything
I've gotten wrong.  If my above explanation is correct, I can answer
your first question:

> First question: Is this new or something we have signed onto
> in the past?

I'm the author of RFC 2983, the initial source of the concepts
in the RFC 4301 text that Bill Sommerfeld quoted, and I was involved
in making sure that RFC 4301 covered that issue.  IMHO, from a Diffserv
and IPsec standpoint, I believe this is new and (as stated above), I
think the vpn-signaled-preemption draft should state and defend this
precedence-aware-traffic-conditioning requirement.  That discussion
could then be expanded to cover your second question:

> Obviously, it is sometimes desirable to set things up this way.
> However if this is new, are we happy with this being a requirement?
> Are there situations where the distribution of traffic precedences is
> sufficiently sensitive that we'd rather make ugly tradeoffs than
> expose it?

I share your concern about this being a requirement.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: saag-bounces@MIT.EDU [mailto:saag-bounces@MIT.EDU] On=20
> Behalf Of Sam Hartman
> Sent: Friday, September 29, 2006 2:34 PM
> To: saag@MIT.EDU; ipsec@ietf.org
> Cc: tsvwg-chairs@tools.ietf.org
> Subject: [saag] tsvwg,preemption and rsvp: exposing=20
> characteristics of confidentialtraffic
>=20
>=20
>=20
>=20
>=20
> There are two RSVP drafts before the IESG or in last call that affect
> the security community.
>=20
>=20
> The first is draft-ietf-tsvwg-rsvp-ipsec and the second is
> draft-ietf-tsvwg-vpn-signal-preemption.
>=20
>=20
> These drafts set up a model under which each precedence class of data
> from a preemption standpoint goes over its own SA and uses its own
> aggregate RSVP reservation.  What that means is you expose on the
> unprotected side of the interface what fraction of your traffic is at
> each precedence level.
>=20
> First question: Is this new or something we have signed onto in the
> past?
>=20
> Obviously, it is sometimes desirable to set things up this way.
> However if this is new, are we happy with this being a requirement?
> Are there situations where the distribution of traffic precedences is
> sufficiently sensitive that we'd rather make ugly tradeoffs than
> expose it?
>=20
>=20
> I'd appreciate your input on these questions and any comments you have
> on the two drafts.
>=20
> Thanks,
>=20
> Sam Hartman
> Security Area Director
>=20
>=20
> _______________________________________________
> saag mailing list
> saag@mit.edu
> http://mailman.mit.edu/mailman/listinfo/saag
>=20

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Fri Sep 29 19:26:20 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GTRhC-0007YH-2O; Fri, 29 Sep 2006 19:23:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GTRhB-0007YC-8X
	for ipsec@ietf.org; Fri, 29 Sep 2006 19:23:05 -0400
Received: from mexforward.lss.emc.com ([128.222.32.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTRh9-00084O-UX
	for ipsec@ietf.org; Fri, 29 Sep 2006 19:23:05 -0400
Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14])
	by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k8TNN0Zb004840; Fri, 29 Sep 2006 19:23:00 -0400 (EDT)
Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com
	[10.254.64.54])
	by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k8TNMw0R013891; Fri, 29 Sep 2006 19:22:58 -0400 (EDT)
From: Black_David@emc.com
Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by
	corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.0); 
	Fri, 29 Sep 2006 19:22:58 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 29 Sep 2006 19:22:57 -0400
Message-ID: <F222151D3323874393F83102D614E05502B6745C@CORPUSMX20A.corp.emc.com>
In-Reply-To: <36E4499D-2CA2-4FAD-B929-26D0482B6220@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [saag] tsvwg, preemption and rsvp: exposing characteristics of
	confidentialtraffic
Thread-Index: AcbkG0Op86EV886IRqGV01JA7DUjjAAASV7Q
To: <fred@cisco.com>
X-OriginalArrivalTime: 29 Sep 2006 23:22:58.0283 (UTC)
	FILETIME=[330623B0:01C6E41E]
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935,
	Antispam-Data: 2006.9.29.155442
X-PerlMx-Spam: Gauge=, SPAM=2%, Reason='EMC_FROM_0+ -2, NO_REAL_NAME 0, __CT 0,
	__CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0,
	__HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0,
	__MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: saag@MIT.EDU, ipsec@ietf.org, tsvwg-chairs@tools.ietf.org,
	hartmans-ietf@MIT.EDU, flefauch@cisco.com
Subject: [Ipsec] RE: [saag] tsvwg,
	preemption and rsvp: exposing characteristics of confidentialtraffic
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org

Fred,

This looks like a good approach.

Please check the rest of the draft for more "residual verbiage
about tunnels", as there's also potentially problematic text in at
least Sections 2.1 and 2.3.1  In 2.1, there are a number of places
where use of singular "reservation" instead of plural "reservations"
may imply that there is one aggregate reservation for the tunnel.

Also, please consider how the approach in this draft ought to be
applied to a PHB that consists of multiple DSCPs (e.g., an AF
class, cf. RFC 2597).  I believe AF is not a good fit to the
sort of traffic that motivated this draft, so explaining that
may suffice.

Thanks,
--David

> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com]=20
> Sent: Friday, September 29, 2006 6:59 PM
> To: Black, David
> Cc: hartmans-ietf@MIT.EDU; saag@MIT.EDU; ipsec@ietf.org;=20
> tsvwg-chairs@tools.ietf.org; flefauch@cisco.com
> Subject: Re: [saag] tsvwg,preemption and rsvp: exposing=20
> characteristics of confidentialtraffic
>=20
> hmm. It sounds like there is some residual verbiage about tunnels in =20
> the vpn-signaled-preemption draft.
>=20
> Bottom line, both drafts call for a common DSCP. Both require =20
> multiple reservations by vport in the RSVP signaling, with the vport =20
> indicating anything that the network administrator wants it to =20
> indicate, and the vpn-signaling draft specifically saying that the =20
> network administrator in question is requesting that it signify call =20
> precedence. Call precedence is, in reality, not signaled by the vport

> number, but by the priorities signaled in the RFC3181-clone priority =20
> (precedence) fields of the rsvp draft, but the values used for the =20
> vports have to be agreed upon throughout the network in order to name

> the resulting reservations so they can be "discussed" among the =20
> equipment.
>=20
> I am willing to clean up the use of "priority" and "precedence" as =20
> you suggest and clean up this paragraph, along with Jari's =20
> "discuss" (as in, "remove a section the principal client of the draft

> asked to have written into it"). I think it's fair to ask for any =20
> remaining IESG comment before doing so...
>=20
> On Sep 29, 2006, at 3:01 PM, Black_David@emc.com wrote:
>=20
> > Actually, only the vpn-signaled-preemption draft appears to do this.
> >
> > The rsvp-ipsec draft allows multiple reservations between the same
> > endpoints for the same DSCP, which would allow such traffic to use
> > different tunnels but if it requires traffic for different
> > reservations to use different tunnels, I was not able to find
> > a statement of that requirement.
> >
> > OTOH, the vpn-signaled-preemption draft is quite clear that
different
> > precedence levels for the same DSCP result in different IPsec
tunnels.
> > Section 2.3.3 says:
> >
> >    Due to
> >    the mechanics of preemption, however, this would not expand the
> >    existing "routine" reservations in the interface and inner
domains,
> >    as doing this causes loss of information - how much of the
> >    reservation is now "routine" and how much is "priority"?  Rather,
> >    this new reservation will open up a separate set of tunnels or
> >    security associations for traffic of its application class at its
> >    precedence between that aggregator and deaggregator.
>=20

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec



From ipsec-bounces@ietf.org Fri Sep 29 20:30:20 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GTShO-00073W-Go; Fri, 29 Sep 2006 20:27:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GTShN-00073Q-HJ
	for ipsec@ietf.org; Fri, 29 Sep 2006 20:27:21 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTShL-0002ZW-53
	for ipsec@ietf.org; Fri, 29 Sep 2006 20:27:21 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k8U0RITR008005
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <ipsec@ietf.org>; Fri, 29 Sep 2006 17:27:18 -0700
Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k8U0RHK9022342
	for <ipsec@ietf.org>; Fri, 29 Sep 2006 17:27:17 -0700 (PDT)
Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by
	NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 29 Sep 2006 17:27:17 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 29 Sep 2006 17:27:12 -0700
Message-ID: <C24CB51D5AA800449982D9BCB90325131A2EE0@NAEX13.na.qualcomm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Clarification on EAP MSK usage in IKEv2
thread-index: AcbkJyyPFyVUxZoaSo6+yR8iWuf/Rw==
From: "Narayanan, Vidya" <vidyan@qualcomm.com>
To: <ipsec@ietf.org>
X-OriginalArrivalTime: 30 Sep 2006 00:27:17.0525 (UTC)
	FILETIME=[2F4FBC50:01C6E427]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Subject: [Ipsec] Clarification on EAP MSK usage in IKEv2
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>,
	<mailto:ipsec-request@ietf.org?subject=subscribe>
Errors-To: ipsec-bounces@ietf.org

All,
RFC4306, in section 2.16, states:=20

"For EAP methods that create a shared key as a side effect of
authentication, that shared key MUST be used by both the initiator and
responder to generate AUTH payloads in messages 7 and 8 using the syntax
for shared secrets specified in section 2.15.  The shared key from EAP
is the field from the EAP specification named MSK.  The shared key
generated during an IKE exchange MUST NOT be used for any other
purpose."=20

This seems to be a bit ambiguous in what constitutes "other purposes".
For instance, let's consider two entities A & B running IKEv2-EAP and
establishing an IKE_SA between themselves, using the MSK for
authentication of the IKE_SA. If A & B were to subsequently run IKEv2
again and establish another IKE_SA, could the same MSK be then used for
authentication here as well?=20

In other words, it seems confusing whether "other purposes" also means
"for other IKEv2 runs between the same initiator and responder".=20

If we drew an analogy from the MSK usage on other EAP lower layers
(e.g., IEEE 802.11i), the same MSK can be used to re-key TSKs between
the same peer and authenticator until expiry of that MSK. By the same
argument, I don't see a reason why the MSK cannot be used again for the
authentication of a subsequent IKE_SA between the IKEv2 initiator and
responder. I can see some exceptions (e.g., where the IKEv2 entity
acting as the EAP peer actually wishes to use different
identity/credentials for the two exchanges, requiring a separate EAP run
for those), but, in general, it seems like we should be able to use the
same MSK for the multiple exchanges.=20

One potential concern is perhaps due to the fact that the MSK is used
directly in the generation of the AUTH payload and if the multiple IKEv2
runs used different prf's for generating the AUTH payload, that could
result in a bad use of the MSK. But, if the same algorithm is used in
the multiple runs, is there still something to be concerned about? And,
would it be a violation of RFC4306?=20

I'd appreciate any clarification on the above. Also, if someone can
provide clarity on what implementations do (e.g., is the MSK deleted
after authenticating the IKE_SA or is it cached for a certain duration,
etc.), that would be very helpful.=20

Thanks,
Vidya

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec