From nobody Mon Sep  1 00:37:29 2014
Return-Path: <ynir.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A51D1A014C for <ipsec@ietfa.amsl.com>; Mon,  1 Sep 2014 00:37:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmhQwJXyNyJ8 for <ipsec@ietfa.amsl.com>; Mon,  1 Sep 2014 00:37:24 -0700 (PDT)
Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789D61A011B for <ipsec@ietf.org>; Mon,  1 Sep 2014 00:37:19 -0700 (PDT)
Received: by mail-we0-f178.google.com with SMTP id u57so4947403wes.23 for <ipsec@ietf.org>; Mon, 01 Sep 2014 00:37:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=v0l3hXPJ3AkgOiKpZYayGJzAywSWAM/2EcLXpn9lajQ=; b=TlOvLKzewUJ9UtGT6uWbEh6VGy1+ZTbzuiKPr8tYhlrFhjihTrXWjXAyuqiKHf8ne2 Y6niA/m3ztaowgxyRuskuXruWCKfBtw4P9hG4t0sn2KlQ2h5u1Mt+LPsJHY7xiwaC5QU Dxd+Y8NZp/b88i+vDtlnfU1LXDDm/vTN6i9BSTZfIrhzZs/Ev4fVHA9SgtSZUttPHRyD bsov9Tc/bsbn9R7+VmuPhGH9CdjonP9n8Cr9wy3vw+6mlyxkg3hQ+xhUIX/3zO5bjuHJ qd6nOtNvxT6L4tmLEzTJvajGS5vv4vB7TOX4l9jZUah6l3Bj69RvTyjrBMjM6jshzaMz OJoQ==
X-Received: by 10.195.12.4 with SMTP id em4mr1028685wjd.98.1409557037576; Mon, 01 Sep 2014 00:37:17 -0700 (PDT)
Received: from [172.24.251.145] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id xa6sm106168wjc.19.2014.09.01.00.37.16 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Sep 2014 00:37:17 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_8A28D0D2-627B-4B68-9AC4-5083D5EDB4D7"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <f349616c76c3467a95239d459bb4fb01@DM2PR0601MB713.namprd06.prod.outlook.com>
Date: Mon, 1 Sep 2014 10:37:13 +0300
Message-Id: <583C5D54-E70D-42AE-845C-79CF5CB8F71F@gmail.com>
References: <f349616c76c3467a95239d459bb4fb01@DM2PR0601MB713.namprd06.prod.outlook.com>
To: Avishek Ganguly <aganguly@ixiacom.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/0vWlapgWZffifKGN16Zscc1Yhps
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec] Question Regarding IKEv2 RFC5996 Use of NO_PROPOSAL_CHOSEN and INVALID_KE_PAYLOAD
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Sep 2014 07:37:27 -0000

--Apple-Mail=_8A28D0D2-627B-4B68-9AC4-5083D5EDB4D7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hi, Avishek

English is not my first language, so I=92m not sure what =93exclusive=94 =
means below, but I hope I can clarify anyways.

Suppose Responder policy is to allow certain groups (say, 19 and 20), =
while the Initiator=92s request includes groups 2, 5, and 14 in the SA =
payload, and group 2 in the KE payload.=20

It seems like both INVALID_KE_PAYLOAD and NO_PROPOSAL_CHOSEN are =
appropriate, but this is not the case. The purpose of the =
INVALID_KE_PAYLOAD is to have the Initiator immediately retry (it says =
so right after the part you quoted) with the correct group. But we =
already no that the Initiator doesn=92t support any of the supported =
groups. If it did, then the SA payload would include them. So in this =
case, only NO_PROPOSAL_CHOSEN is appropriate.

NO_PROPOSAL_CHOSEN is the kind of error that is not correctable without =
configuration changes. INVALID_KE_PAYLOAD is an error that should be =
automatically corrected immediately.

So although it doesn=92t say so explicitly in the RFC, you really need =
to evaluate the SA payload first. It might not be worth it to check the =
others.

Hope this helps

Yoav

On Sep 1, 2014, at 7:28 AM, Avishek Ganguly <aganguly@ixiacom.com> =
wrote:

> Hello,
> =20
> I have questions regarding use of NO_PROPOSAL_CHOSEN and =
INVALID_KE_PAYLOAD in IKE_SA_INIT exchange in RFC 5996 IKEv2.
> According to
> "Section 3.10.1.  Notify Message Types
> NO_PROPOSAL_CHOSEN                       14
>       None of the proposed crypto suites was acceptable.  This can be
>       sent in any case where the offered proposals (including but not
>       limited to SA payload values, USE_TRANSPORT_MODE notify,
>       IPCOMP_SUPPORTED notify) are not acceptable for the responder.
> "
> according to the above statement it is meant that if initiator sends a =
proposal with a Diffie-Hellman group value that is unacceptable by the =
responder, then responder must send a NO_PROPOSAL_CHOSEN notification.
> =20
> But according to
> "Section 1.2. The Initial Exchanges
> Because the initiator sends its Diffie-Hellman value in the
>    IKE_SA_INIT, it must guess the Diffie-Hellman group that the
>    responder will select from its list of supported groups.  If the
>    initiator guesses wrong, the responder will respond with a Notify
>    payload of type INVALID_KE_PAYLOAD indicating the selected group.
> "
> =46rom the INVALID_KE_PAYLOAD description stated above means that =
NO_PROPOSAL_CHOSEN case is exclusive of this INVALID_KE_PAYLOAD.
> =20
> Is it right interpretation of the above two error types ?
> =20
> Thanks and Regards,
> Avishek
> =20
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec


--Apple-Mail=_8A28D0D2-627B-4B68-9AC4-5083D5EDB4D7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi, =
Avishek<div><br></div><div>English is not my first language, so I=92m =
not sure what =93exclusive=94 means below, but I hope I can clarify =
anyways.</div><div><br></div><div>Suppose Responder policy is to allow =
certain groups (say, 19 and 20), while the Initiator=92s request =
includes groups 2, 5, and 14 in the SA payload, and group 2 in the KE =
payload.&nbsp;</div><div><br></div><div>It seems like both =
INVALID_KE_PAYLOAD and NO_PROPOSAL_CHOSEN are appropriate, but this is =
not the case. The purpose of the INVALID_KE_PAYLOAD is to have the =
Initiator immediately retry (it says so right after the part you quoted) =
with the correct group. But we already no that the Initiator doesn=92t =
support any of the supported groups. If it did, then the SA payload =
would include them. So in this case, only NO_PROPOSAL_CHOSEN is =
appropriate.</div><div><br></div><div>NO_PROPOSAL_CHOSEN is the kind of =
error that is not correctable without configuration changes. =
INVALID_KE_PAYLOAD is an error that should be automatically corrected =
immediately.</div><div><br></div><div>So although it doesn=92t say so =
explicitly in the RFC, you really need to evaluate the SA payload first. =
It might not be worth it to check the =
others.</div><div><br></div><div>Hope this =
helps</div><div><br></div><div>Yoav</div><div><br><div><div>On Sep 1, =
2014, at 7:28 AM, Avishek Ganguly &lt;<a =
href=3D"mailto:aganguly@ixiacom.com">aganguly@ixiacom.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72" =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;"><div class=3D"WordSection1" =
style=3D"page: WordSection1;"><div style=3D"margin: 0in 0in 0.0001pt; =
font-size: 11pt; font-family: Calibri, =
sans-serif;">Hello,<o:p></o:p></div><div style=3D"margin: 0in 0in =
0.0001pt; font-size: 11pt; font-family: Calibri, =
sans-serif;"><o:p>&nbsp;</o:p></div><div style=3D"margin: 0in 0in =
0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">I have =
questions regarding use of NO_PROPOSAL_CHOSEN and INVALID_KE_PAYLOAD in =
IKE_SA_INIT exchange in RFC 5996 IKEv2.<o:p></o:p></div><div =
style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;">According to<o:p></o:p></div><div style=3D"margin: =
0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, =
sans-serif;">"Section 3.10.1.&nbsp; Notify Message =
Types<o:p></o:p></div><div style=3D"margin: 0in 0in 0.0001pt; font-size: =
11pt; font-family: Calibri, =
sans-serif;">NO_PROPOSAL_CHOSEN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; 14<o:p></o:p></div><div style=3D"margin: 0in 0in =
0.0001pt; font-size: 11pt; font-family: Calibri, =
sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; None of the proposed crypto =
suites was acceptable.&nbsp; This can be<o:p></o:p></div><div =
style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sent in any case =
where the offered proposals (including but not<o:p></o:p></div><div =
style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; limited to SA =
payload values, USE_TRANSPORT_MODE notify,<o:p></o:p></div><div =
style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IPCOMP_SUPPORTED =
notify) are not acceptable for the responder.<o:p></o:p></div><div =
style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;">"<o:p></o:p></div><div style=3D"margin: 0in 0in =
0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">according =
to the above statement it is meant that if initiator sends a proposal =
with a Diffie-Hellman group value that is unacceptable by the responder, =
then responder must send a NO_PROPOSAL_CHOSEN =
notification.<o:p></o:p></div><div style=3D"margin: 0in 0in 0.0001pt; =
font-size: 11pt; font-family: Calibri, =
sans-serif;"><o:p>&nbsp;</o:p></div><div style=3D"margin: 0in 0in =
0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">But =
according to<o:p></o:p></div><div style=3D"margin: 0in 0in 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;">"Section 1.2. The =
Initial Exchanges<o:p></o:p></div><div style=3D"margin: 0in 0in =
0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">Because =
the initiator sends its Diffie-Hellman value in the<o:p></o:p></div><div =
style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;">&nbsp;&nbsp; IKE_SA_INIT, it must guess the =
Diffie-Hellman group that the<o:p></o:p></div><div style=3D"margin: 0in =
0in 0.0001pt; font-size: 11pt; font-family: Calibri, =
sans-serif;">&nbsp;&nbsp; responder will select from its list of =
supported groups.&nbsp; If the<o:p></o:p></div><div style=3D"margin: 0in =
0in 0.0001pt; font-size: 11pt; font-family: Calibri, =
sans-serif;">&nbsp;&nbsp; initiator guesses wrong, the responder will =
respond with a Notify<o:p></o:p></div><div style=3D"margin: 0in 0in =
0.0001pt; font-size: 11pt; font-family: Calibri, =
sans-serif;">&nbsp;&nbsp; payload of type INVALID_KE_PAYLOAD indicating =
the selected group.<o:p></o:p></div><div style=3D"margin: 0in 0in =
0.0001pt; font-size: 11pt; font-family: Calibri, =
sans-serif;">"<o:p></o:p></div><div style=3D"margin: 0in 0in 0.0001pt; =
font-size: 11pt; font-family: Calibri, sans-serif;">=46rom the =
INVALID_KE_PAYLOAD description stated above means that =
NO_PROPOSAL_CHOSEN case is exclusive of this =
INVALID_KE_PAYLOAD.<o:p></o:p></div><div style=3D"margin: 0in 0in =
0.0001pt; font-size: 11pt; font-family: Calibri, =
sans-serif;"><o:p>&nbsp;</o:p></div><div style=3D"margin: 0in 0in =
0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">Is it =
right interpretation of the above two error types ?<o:p></o:p></div><div =
style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: =
Calibri, sans-serif;"><o:p>&nbsp;</o:p></div><div style=3D"margin: 0in =
0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;">Thanks =
and Regards,<o:p></o:p></div><div style=3D"margin: 0in 0in 0.0001pt; =
font-size: 11pt; font-family: Calibri, =
sans-serif;">Avishek<o:p></o:p></div><div style=3D"margin: 0in 0in =
0.0001pt; font-size: 11pt; font-family: Calibri, =
sans-serif;"><o:p>&nbsp;</o:p></div></div>________________________________=
_______________<br>IPsec mailing list<br><a href=3D"mailto:IPsec@ietf.org"=
 style=3D"color: rgb(149, 79, 114); text-decoration: =
underline;">IPsec@ietf.org</a><br><a =
href=3D"https://www.ietf.org/mailman/listinfo/ipsec" style=3D"color: =
rgb(149, 79, 114); text-decoration: =
underline;">https://www.ietf.org/mailman/listinfo/ipsec</a></div></blockqu=
ote></div><br></div></body></html>=

--Apple-Mail=_8A28D0D2-627B-4B68-9AC4-5083D5EDB4D7--


From nobody Mon Sep  1 02:01:57 2014
Return-Path: <aganguly@ixiacom.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082EE1A014E for <ipsec@ietfa.amsl.com>; Mon,  1 Sep 2014 02:01:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.131
X-Spam-Level: 
X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQ5CvO5H73L4 for <ipsec@ietfa.amsl.com>; Mon,  1 Sep 2014 02:01:45 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B16E1A0282 for <ipsec@ietf.org>; Mon,  1 Sep 2014 02:01:45 -0700 (PDT)
Received: from DM2PR0601MB713.namprd06.prod.outlook.com (10.242.115.155) by DM2PR0601MB715.namprd06.prod.outlook.com (10.242.126.11) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Mon, 1 Sep 2014 09:01:43 +0000
Received: from DM2PR0601MB713.namprd06.prod.outlook.com ([10.242.115.155]) by DM2PR0601MB713.namprd06.prod.outlook.com ([10.242.115.155]) with mapi id 15.00.1015.018; Mon, 1 Sep 2014 09:01:43 +0000
From: Avishek Ganguly <aganguly@ixiacom.com>
To: "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: [IPsec] Question Regarding IKEv2 RFC5996 Use of NO_PROPOSAL_CHOSEN and INVALID_KE_PAYLOAD
Thread-Index: Ac/FnSWEFTen3/ebTi+t+niQ7k32vQAGmYmAAAKv+ZA=
Date: Mon, 1 Sep 2014 09:01:42 +0000
Message-ID: <63f489b81d784a368106e901e5d62abb@DM2PR0601MB713.namprd06.prod.outlook.com>
References: <f349616c76c3467a95239d459bb4fb01@DM2PR0601MB713.namprd06.prod.outlook.com> <583C5D54-E70D-42AE-845C-79CF5CB8F71F@gmail.com>
In-Reply-To: <583C5D54-E70D-42AE-845C-79CF5CB8F71F@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [121.242.14.67]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;
x-forefront-prvs: 03218BFD9F
x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(129404003)(199003)(24454002)(377454003)(101416001)(19625215002)(76482001)(85852003)(74662001)(21056001)(15975445006)(19609705001)(79102001)(95666004)(107046002)(76176999)(77982001)(20776003)(107886001)(15202345003)(90102001)(99286002)(2501002)(31966008)(19300405004)(87936001)(2351001)(33646002)(105586002)(76576001)(54356999)(108616004)(74502001)(74316001)(19580395003)(83322001)(2656002)(16236675004)(106356001)(80022001)(4396001)(46102001)(81342001)(110136001)(86362001)(50986999)(561944003)(66066001)(19617315012)(85306004)(19580405001)(92566001)(81542001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR0601MB715; H:DM2PR0601MB713.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_63f489b81d784a368106e901e5d62abbDM2PR0601MB713namprd06p_"
MIME-Version: 1.0
X-OriginatorOrg: ixiacom.com
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 04
X-MS-Exchange-CrossPremises-AuthSource: DM2PR0601MB713.namprd06.prod.outlook.com
X-MS-Exchange-CrossPremises-SCL: 1
X-MS-Exchange-CrossPremises-messagesource: StoreDriver
X-MS-Exchange-CrossPremises-BCC: 
X-MS-Exchange-CrossPremises-originalclientipaddress: 121.242.14.67
X-MS-Exchange-CrossPremises-avstamp-service: 1.0
X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; 
X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent
X-OrganizationHeadersPreserved: DM2PR0601MB715.namprd06.prod.outlook.com
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/0IUSVBaYVLshIg-VWJS9zbtN0Rs
Subject: Re: [IPsec] Question Regarding IKEv2 RFC5996 Use of NO_PROPOSAL_CHOSEN and INVALID_KE_PAYLOAD
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Sep 2014 09:01:50 -0000

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

Thanks Yoav for your explanation.

> English is not my first language, so I'm not sure what "exclusive" means =
below, but I hope I can clarify anyways.

By exclusive I mean NO_PROPOSAL_CHOSEN is an error that is not generated be=
cause of any DH Group mismatches in KE Payload.


So it seems that INVALID_KE_PAYLOAD is an error that should be generated du=
ring CREATE_CHILD_SA exchange. And NO_PROPOSAL_CHOSEN is appropriate for IK=
E_SA_INIT. Because Before IKE_SA_INIT responder does not know which groups =
initiator supports. When responder gets a IKE_SA_INIT with invalid DH GROUP
It should assume that there is some configuration issues from initiator sid=
e.

Regards,
Avishek
From: Yoav Nir [mailto:ynir.ietf@gmail.com]
Sent: Monday, September 01, 2014 1:07 PM
To: Avishek Ganguly
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Question Regarding IKEv2 RFC5996 Use of NO_PROPOSAL_CH=
OSEN and INVALID_KE_PAYLOAD

Hi, Avishek

English is not my first language, so I'm not sure what "exclusive" means be=
low, but I hope I can clarify anyways.

Suppose Responder policy is to allow certain groups (say, 19 and 20), while=
 the Initiator's request includes groups 2, 5, and 14 in the SA payload, an=
d group 2 in the KE payload.

It seems like both INVALID_KE_PAYLOAD and NO_PROPOSAL_CHOSEN are appropriat=
e, but this is not the case. The purpose of the INVALID_KE_PAYLOAD is to ha=
ve the Initiator immediately retry (it says so right after the part you quo=
ted) with the correct group. But we already no that the Initiator doesn't s=
upport any of the supported groups. If it did, then the SA payload would in=
clude them. So in this case, only NO_PROPOSAL_CHOSEN is appropriate.

NO_PROPOSAL_CHOSEN is the kind of error that is not correctable without con=
figuration changes. INVALID_KE_PAYLOAD is an error that should be automatic=
ally corrected immediately.

So although it doesn't say so explicitly in the RFC, you really need to eva=
luate the SA payload first. It might not be worth it to check the others.

Hope this helps

Yoav

On Sep 1, 2014, at 7:28 AM, Avishek Ganguly <aganguly@ixiacom.com<mailto:ag=
anguly@ixiacom.com>> wrote:


Hello,

I have questions regarding use of NO_PROPOSAL_CHOSEN and INVALID_KE_PAYLOAD=
 in IKE_SA_INIT exchange in RFC 5996 IKEv2.
According to
"Section 3.10.1.  Notify Message Types
NO_PROPOSAL_CHOSEN                       14
      None of the proposed crypto suites was acceptable.  This can be
      sent in any case where the offered proposals (including but not
      limited to SA payload values, USE_TRANSPORT_MODE notify,
      IPCOMP_SUPPORTED notify) are not acceptable for the responder.
"
according to the above statement it is meant that if initiator sends a prop=
osal with a Diffie-Hellman group value that is unacceptable by the responde=
r, then responder must send a NO_PROPOSAL_CHOSEN notification.

But according to
"Section 1.2. The Initial Exchanges
Because the initiator sends its Diffie-Hellman value in the
   IKE_SA_INIT, it must guess the Diffie-Hellman group that the
   responder will select from its list of supported groups.  If the
   initiator guesses wrong, the responder will respond with a Notify
   payload of type INVALID_KE_PAYLOAD indicating the selected group.
"
>From the INVALID_KE_PAYLOAD description stated above means that NO_PROPOSAL=
_CHOSEN case is exclusive of this INVALID_KE_PAYLOAD.

Is it right interpretation of the above two error types ?

Thanks and Regards,
Avishek

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


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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:m=3D"http://schema=
s.microsoft.com/office/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html=
40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:795416505;
	mso-list-type:hybrid;
	mso-list-template-ids:-665160364 -389102626 67698691 67698693 67698689 676=
98691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:\F0D8;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l0:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l0:level4
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l0:level5
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l0:level6
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l0:level7
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l0:level8
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l0:level9
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l1
	{mso-list-id:1736392343;
	mso-list-type:hybrid;
	mso-list-template-ids:839527884 67698699 67698691 67698693 67698689 676986=
91 67698693 67698689 67698691 67698693;}
@list l1:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:\F0D8;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";}
@list l1:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l1:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l1:level4
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l1:level5
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l1:level6
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l1:level7
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l1:level8
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l1:level9
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks Yoav for your expl=
anation.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal">&gt; English is not my first language, so I&#8217;m =
not sure what &#8220;exclusive&#8221; means below, but I hope I can clarify=
 anyways.<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">By exclusive I mean NO_PR=
OPOSAL_CHOSEN is an error that is not generated because of any DH Group mis=
matches in KE Payload.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">So it seems that INVALID_=
KE_PAYLOAD is an error that should be generated during CREATE_CHILD_SA exch=
ange. And NO_PROPOSAL_CHOSEN is appropriate for IKE_SA_INIT.
 Because Before IKE_SA_INIT responder does not know which groups initiator =
supports. When responder gets a IKE_SA_INIT with invalid DH GROUP<o:p></o:p=
></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">It should assume that the=
re is some configuration issues from initiator side.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Regards,<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Avishek<o:p></o:p></span>=
</p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-=
size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"> Yoav N=
ir [mailto:ynir.ietf@gmail.com]
<br>
<b>Sent:</b> Monday, September 01, 2014 1:07 PM<br>
<b>To:</b> Avishek Ganguly<br>
<b>Cc:</b> ipsec@ietf.org<br>
<b>Subject:</b> Re: [IPsec] Question Regarding IKEv2 RFC5996 Use of NO_PROP=
OSAL_CHOSEN and INVALID_KE_PAYLOAD<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Hi, Avishek<o:p></o:p></p>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">English is not my first language, so I&#8217;m not s=
ure what &#8220;exclusive&#8221; means below, but I hope I can clarify anyw=
ays.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Suppose Responder policy is to allow certain groups =
(say, 19 and 20), while the Initiator&#8217;s request includes groups 2, 5,=
 and 14 in the SA payload, and group 2 in the KE payload.&nbsp;<o:p></o:p><=
/p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">It seems like both INVALID_KE_PAYLOAD and NO_PROPOSA=
L_CHOSEN are appropriate, but this is not the case. The purpose of the INVA=
LID_KE_PAYLOAD is to have the Initiator immediately retry (it says so right=
 after the part you quoted) with the
 correct group. But we already no that the Initiator doesn&#8217;t support =
any of the supported groups. If it did, then the SA payload would include t=
hem. So in this case, only NO_PROPOSAL_CHOSEN is appropriate.<o:p></o:p></p=
>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">NO_PROPOSAL_CHOSEN is the kind of error that is not =
correctable without configuration changes. INVALID_KE_PAYLOAD is an error t=
hat should be automatically corrected immediately.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">So although it doesn&#8217;t say so explicitly in th=
e RFC, you really need to evaluate the SA payload first. It might not be wo=
rth it to check the others.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Hope this helps<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Yoav<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<div>
<p class=3D"MsoNormal">On Sep 1, 2014, at 7:28 AM, Avishek Ganguly &lt;<a h=
ref=3D"mailto:aganguly@ixiacom.com">aganguly@ixiacom.com</a>&gt; wrote:<o:p=
></o:p></p>
</div>
<p class=3D"MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Hello,<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">I have questions regarding use of NO_PR=
OPOSAL_CHOSEN and INVALID_KE_PAYLOAD in IKE_SA_INIT exchange in RFC 5996 IK=
Ev2.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">According to<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&quot;Section 3.10.1.&nbsp; Notify Mess=
age Types<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">NO_PROPOSAL_CHOSEN&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 14<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; None of =
the proposed crypto suites was acceptable.&nbsp; This can be<o:p></o:p></sp=
an></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sent in =
any case where the offered proposals (including but not<o:p></o:p></span></=
p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; limited =
to SA payload values, USE_TRANSPORT_MODE notify,<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IPCOMP_S=
UPPORTED notify) are not acceptable for the responder.<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&quot;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">according to the above statement it is =
meant that if initiator sends a proposal with a Diffie-Hellman group value =
that is unacceptable by the responder, then responder must
 send a NO_PROPOSAL_CHOSEN notification.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">But according to<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&quot;Section 1.2. The Initial Exchange=
s<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Because the initiator sends its Diffie-=
Hellman value in the<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;&nbsp; IKE_SA_INIT, it must guess=
 the Diffie-Hellman group that the<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;&nbsp; responder will select from=
 its list of supported groups.&nbsp; If the<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;&nbsp; initiator guesses wrong, t=
he responder will respond with a Notify<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;&nbsp; payload of type INVALID_KE=
_PAYLOAD indicating the selected group.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&quot;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">From the INVALID_KE_PAYLOAD description=
 stated above means that NO_PROPOSAL_CHOSEN case is exclusive of this INVAL=
ID_KE_PAYLOAD.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Is it right interpretation of the above=
 two error types ?<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Thanks and Regards,<o:p></o:p></span></=
p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Avishek<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:&quot;Hel=
vetica&quot;,&quot;sans-serif&quot;">______________________________________=
_________<br>
IPsec mailing list<br>
</span><a href=3D"mailto:IPsec@ietf.org"><span style=3D"font-size:9.0pt;fon=
t-family:&quot;Helvetica&quot;,&quot;sans-serif&quot;;color:#954F72">IPsec@=
ietf.org</span></a><span style=3D"font-size:9.0pt;font-family:&quot;Helveti=
ca&quot;,&quot;sans-serif&quot;"><br>
</span><a href=3D"https://www.ietf.org/mailman/listinfo/ipsec"><span style=
=3D"font-size:9.0pt;font-family:&quot;Helvetica&quot;,&quot;sans-serif&quot=
;;color:#954F72">https://www.ietf.org/mailman/listinfo/ipsec</span></a><spa=
n style=3D"font-size:9.0pt;font-family:&quot;Helvetica&quot;,&quot;sans-ser=
if&quot;"><o:p></o:p></span></p>
</div>
</blockquote>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</div>
</body>
</html>

--_000_63f489b81d784a368106e901e5d62abbDM2PR0601MB713namprd06p_--


From nobody Mon Sep  1 02:17:18 2014
Return-Path: <ynir.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9458F1A02E8 for <ipsec@ietfa.amsl.com>; Mon,  1 Sep 2014 02:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldsX-KZDXE35 for <ipsec@ietfa.amsl.com>; Mon,  1 Sep 2014 02:17:08 -0700 (PDT)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE0461A02E3 for <ipsec@ietf.org>; Mon,  1 Sep 2014 02:17:06 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id 10so5667126lbg.3 for <ipsec@ietf.org>; Mon, 01 Sep 2014 02:17:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=cqY3VewTDR/dsuPcSFUmJh3vx1QyMX+IfnTnupENFf8=; b=T5wRbvGqJWsTsbe5D4VyxayjkLJgC/6aYx0tuLfAp17KmR9qdI024JcZgM0MQsCTNi A+zEOqohrvupDMK7bEziYzMzWDMvHbCpuxl4Yvbhiu+krLkDC9ujkXu5N6H5AABB/bhC JPf2qRnrjAh+ds0smDtUtwVgIC4QWjQPOMCnrfT/Xvbv0qN0BT7gUeYer6tD6BtTVdMd 2MRTO6wXh14rnaYw+o6saLDEJsfe5IcHsMPnfvKpSjZvx2gRaIGpINTg8ScNoydUSEUP 6XnegekkBd+ydPp3i+IfGyucTNde5MsKUXXL195hhwnY1VkHcclh7cmgaPIzdYL+K2IX YogQ==
X-Received: by 10.112.147.74 with SMTP id ti10mr26021693lbb.29.1409563025197;  Mon, 01 Sep 2014 02:17:05 -0700 (PDT)
Received: from [172.24.251.145] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id m5sm174882laa.37.2014.09.01.02.17.03 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Sep 2014 02:17:04 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_943F574A-0672-499F-8C27-7A03BF866254"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <63f489b81d784a368106e901e5d62abb@DM2PR0601MB713.namprd06.prod.outlook.com>
Date: Mon, 1 Sep 2014 12:17:00 +0300
Message-Id: <8EE786E7-5AFE-4224-91CB-0029ABB1735A@gmail.com>
References: <f349616c76c3467a95239d459bb4fb01@DM2PR0601MB713.namprd06.prod.outlook.com> <583C5D54-E70D-42AE-845C-79CF5CB8F71F@gmail.com> <63f489b81d784a368106e901e5d62abb@DM2PR0601MB713.namprd06.prod.outlook.com>
To: Avishek Ganguly <aganguly@ixiacom.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/aUT4DKupdpqhHnmzZFbSb3CtnPI
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec] Question Regarding IKEv2 RFC5996 Use of NO_PROPOSAL_CHOSEN and INVALID_KE_PAYLOAD
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Sep 2014 09:17:10 -0000

--Apple-Mail=_943F574A-0672-499F-8C27-7A03BF866254
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Sep 1, 2014, at 12:01 PM, Avishek Ganguly <aganguly@ixiacom.com> =
wrote:

> Thanks Yoav for your explanation.
> =20
> > English is not my first language, so I=92m not sure what =93exclusive=94=
 means below, but I hope I can clarify anyways.
> =20
> By exclusive I mean NO_PROPOSAL_CHOSEN is an error that is not =
generated because of any DH Group mismatches in KE Payload.
> =20
> =20
> So it seems that INVALID_KE_PAYLOAD is an error that should be =
generated during CREATE_CHILD_SA exchange. And NO_PROPOSAL_CHOSEN is =
appropriate for IKE_SA_INIT. Because Before IKE_SA_INIT responder does =
not know which groups initiator supports. When responder gets a =
IKE_SA_INIT with invalid DH GROUP
> It should assume that there is some configuration issues from =
initiator side.
> =20

No. Both are appropriate in both exchanges.

Both CCSA and IKE_SA_INIT have SA payloads and KE payloads. Since there =
is no requirement that the new (rekeyed) IKE SA have the same algorithms =
and groups of the old IKE SA, the proposals may be different.=20

Regardless of whether we are creating a new authenticated IKE SA, a =
Child SA with PFS or a rekeyed IKE SA, you could have an empty =
intersection of group sets (leading to a NO_PROPOSAL_CHOSEN) or a wrong =
choice of group in KE payload (leading to INVALID_KE_PAYLOAD)


--Apple-Mail=_943F574A-0672-499F-8C27-7A03BF866254
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On Sep 1, 2014, at 12:01 PM, Avishek =
Ganguly &lt;<a =
href=3D"mailto:aganguly@ixiacom.com">aganguly@ixiacom.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div lang=3D"EN-US" link=3D"blue" vlink=3D"purple" =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;"><div class=3D"WordSection1" =
style=3D"page: WordSection1;"><div style=3D"margin: 0in 0in 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif;"><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125);">Thanks Yoav for your =
explanation.<o:p></o:p></span></div><div style=3D"margin: 0in 0in =
0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125);">&nbsp;</span></div><div style=3D"margin: 0in 0in =
0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;">&gt; =
English is not my first language, so I=92m not sure what =93exclusive=94 =
means below, but I hope I can clarify anyways.<o:p></o:p></div><div =
style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times =
New Roman', serif;"><span style=3D"font-size: 11pt; font-family: =
Calibri, sans-serif; color: rgb(31, 73, 125);">&nbsp;</span></div><div =
style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times =
New Roman', serif;"><span style=3D"font-size: 11pt; font-family: =
Calibri, sans-serif; color: rgb(31, 73, 125);">By exclusive I mean =
NO_PROPOSAL_CHOSEN is an error that is not generated because of any DH =
Group mismatches in KE Payload.<o:p></o:p></span></div><div =
style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times =
New Roman', serif;"><span style=3D"font-size: 11pt; font-family: =
Calibri, sans-serif; color: rgb(31, 73, 125);">&nbsp;</span></div><div =
style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times =
New Roman', serif;"><span style=3D"font-size: 11pt; font-family: =
Calibri, sans-serif; color: rgb(31, 73, 125);">&nbsp;</span></div><div =
style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times =
New Roman', serif;"><span style=3D"font-size: 11pt; font-family: =
Calibri, sans-serif; color: rgb(31, 73, 125);">So it seems that =
INVALID_KE_PAYLOAD is an error that should be generated during =
CREATE_CHILD_SA exchange. And NO_PROPOSAL_CHOSEN is appropriate for =
IKE_SA_INIT. Because Before IKE_SA_INIT responder does not know which =
groups initiator supports. When responder gets a IKE_SA_INIT with =
invalid DH GROUP<o:p></o:p></span></div><div style=3D"margin: 0in 0in =
0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125);">It should assume that there is some configuration =
issues from initiator side.<o:p></o:p></span></div><div style=3D"margin: =
0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', =
serif;"><span style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, =
125);">&nbsp;</span></div></div></div></blockquote><br></div><div>No. =
Both are appropriate in both exchanges.</div><div><br></div><div>Both =
CCSA and IKE_SA_INIT have SA payloads and KE payloads. Since there is no =
requirement that the new (rekeyed) IKE SA have the same algorithms and =
groups of the old IKE SA, the proposals may be =
different.&nbsp;</div><div><br></div><div>Regardless of whether we are =
creating a new authenticated IKE SA, a Child SA with PFS or a rekeyed =
IKE SA, you could have an empty intersection of group sets (leading to a =
NO_PROPOSAL_CHOSEN) or a wrong choice of group in KE payload (leading to =
INVALID_KE_PAYLOAD)</div><br></body></html>=

--Apple-Mail=_943F574A-0672-499F-8C27-7A03BF866254--


From nobody Mon Sep  1 07:39:27 2014
Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119971A0A92 for <ipsec@ietfa.amsl.com>; Mon,  1 Sep 2014 07:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.789
X-Spam-Level: 
X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4wlvGf2e-Mk for <ipsec@ietfa.amsl.com>; Mon,  1 Sep 2014 07:39:21 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319791A0977 for <ipsec@ietf.org>; Mon,  1 Sep 2014 07:16:18 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s81EGECJ015508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 1 Sep 2014 17:16:14 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s81EGD5O019563; Mon, 1 Sep 2014 17:16:13 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21508.32685.533369.15287@fireball.kivinen.iki.fi>
Date: Mon, 1 Sep 2014 17:16:13 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Avishek Ganguly <aganguly@ixiacom.com>
In-Reply-To: <f349616c76c3467a95239d459bb4fb01@DM2PR0601MB713.namprd06.prod.outlook.com>
References: <f349616c76c3467a95239d459bb4fb01@DM2PR0601MB713.namprd06.prod.outlook.com>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 10 min
X-Total-Time: 10 min
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/neRr0YGEPySGMmmChopfM0Gm-sg
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: [IPsec] Question Regarding IKEv2 RFC5996 Use of NO_PROPOSAL_CHOSEN and INVALID_KE_PAYLOAD
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Sep 2014 14:39:26 -0000

Avishek Ganguly writes:
> I have questions regarding use of NO_PROPOSAL_CHOSEN and
> INVALID_KE_PAYLOAD in 
> IKE_SA_INIT exchange in RFC 5996 IKEv2.
> 
> According to
> 
> "Section 3.10.1.  Notify Message Types
> 
> NO_PROPOSAL_CHOSEN                       14
>       None of the proposed crypto suites was acceptable.  This can be
>       sent in any case where the offered proposals (including but not
>       limited to SA payload values, USE_TRANSPORT_MODE notify,
>       IPCOMP_SUPPORTED notify) are not acceptable for the responder.
> "
> 
> according to the above statement it is meant that if initiator sends a
> proposal with a Diffie-Hellman group value that is unacceptable by the
> responder, then responder must send a NO_PROPOSAL_CHOSEN notification.

There is no must in the NO_PROPOSAL_CHOSEN text. It says "This can be
sent...".

In general what IKEv2 error message you get back depends on the
implementation and about the order where the implementation parses
things.

For example some implementation might check the SA first and return
NO_PROPOSAL_CHOSEN, but other implementation might check the SA limit
first and return NO_ADDITIONAL_SAS if SA limit is already reached.

Another similar case might be for example TS_UNACCEPTABLE error. Some
implementations do have catch-all policy which says no algorithm
proposal is valid for other addresses, thus instead of returning
TS_UNACCEPTABLE error when proposed something that is outside their
policy, they always return NO_PROPOSAL_CHOSEN as regardless what
initiator proposed it cannot fullfill their no algorithm is allowed
policy...

So do not try to guess what error other end might return...

> But according to
> 
> "Section 1.2. The Initial Exchanges
> Because the initiator sends its Diffie-Hellman value in the
>    IKE_SA_INIT, it must guess the Diffie-Hellman group that the
>    responder will select from its list of supported groups.  If the
>    initiator guesses wrong, the responder will respond with a Notify
>    payload of type INVALID_KE_PAYLOAD indicating the selected group.
> "
> 
> From the INVALID_KE_PAYLOAD description stated above means that
> NO_PROPOSAL_CHOSEN case is exclusive of this INVALID_KE_PAYLOAD.

INVALID_KE_PAYLOAD is special case, as it is not really an error
notification, it is notification telling that yes, your proposal was
ok, but you selected wrong group in your KE payload, please try again
with correct group.

I.e. the INVALID_KE_PAYLOAD is used if the initiator used group in KE
payload that is not allowed by the responder, but included some other
group that is acceptable in the SA payload. I.e. if there is a way to
recover, then you send INVALID_KE_PAYLOAD and tell which group should
be used.

If none of the groups in the SA payload is acceptable then you send
NO_PROPOSAL_CHOSEN, as there is no way to continue, without changing
the policy.
-- 
kivinen@iki.fi


From nobody Tue Sep  2 06:46:39 2014
Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA79A1A03C2 for <ipsec@ietfa.amsl.com>; Tue,  2 Sep 2014 06:46:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.561
X-Spam-Level: 
X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OwAUP9I-U9Y for <ipsec@ietfa.amsl.com>; Tue,  2 Sep 2014 06:46:29 -0700 (PDT)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8031A1A8756 for <ipsec@ietf.org>; Tue,  2 Sep 2014 06:46:05 -0700 (PDT)
Received: by mail-la0-f48.google.com with SMTP id gl10so7896608lab.35 for <ipsec@ietf.org>; Tue, 02 Sep 2014 06:45:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:from:to:subject:date:mime-version:content-type :content-transfer-encoding; bh=fsTqltUSMjX6zvmhJFprXrPXI2pBlQJnrJUV5+5sKdc=; b=R8jTyvULP9iQCvcFOTpvVZzZ38Gthks7tC85xblIl6cDowiFNDXWVR2I/WMe+PqtEJ ++sRLQ8umo2b7QxtiFDw2ja5sDQjXa4ENeupI/+ZK/xEEJZqpSUec6WUpkwFIrUZPu2R nR8T12pTCDWnLfS0ctGmH22CxkGxeFGjIJMSCliwfqeyaOQFPX3u6v7ckWEuAkrc0m4N 6CMfJFVqR10Rp5lgzjQm+wNnSXU0/DMAByoOTOyqqh2RcfHfWTKki1tjmhzXuvyVSST3 s5MXnWlho3X2rrRsmKeYZpxFP857lot3hzGvQf0OQnsAQMhmPZE6rAM5dbdrXVonnYs4 aa6A==
X-Received: by 10.152.22.170 with SMTP id e10mr35467765laf.30.1409665558005; Tue, 02 Sep 2014 06:45:58 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id y5sm2544592laa.20.2014.09.02.06.45.56 for <ipsec@ietf.org> (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 02 Sep 2014 06:45:57 -0700 (PDT)
Message-ID: <164B71A9D45447FEBDD4560944B3C740@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: <ipsec@ietf.org>
Date: Tue, 2 Sep 2014 17:46:00 +0400
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/mScKP_8WZs2LiB8lCcip05ndB2w
Subject: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-03.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Sep 2014 13:46:31 -0000

Hi all,

I've posted a new version of the draft-smyslov-ipsecme-ikev2-null-auth.
It has the following differences from previous:

1. New Identity Type ID_NULL is introduced to indicate that
    no Identity is provided (instead of using reserved value 0 for this 
purpose)
2. The door opener example is replaced with the remote sensor example.
3. Security Consideration Section is updated.

I still have an issue with the naming. Probably the "NULL Authentication"
and the "ID_NULL" are not the most appropriate variants, but nobody from
the vast majority of list subscribers, who have english as their
native language, clearly let me know that yet and suggest better variants.

Regards,
Valery Smyslov.


> A new version of I-D, draft-smyslov-ipsecme-ikev2-null-auth-03.txt
> has been successfully submitted by Valery Smyslov and posted to the
> IETF repository.
>
> Name: draft-smyslov-ipsecme-ikev2-null-auth
> Revision: 03
> Title: The NULL Authentication Method in IKEv2 Protocol
> Document date: 2014-09-02
> Group: Individual Submission
> Pages: 9
> URL: 
> http://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-ikev2-null-auth-03.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-null-auth/
> Htmlized: 
> http://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-null-auth-03
> Diff: 
> http://www.ietf.org/rfcdiff?url2=draft-smyslov-ipsecme-ikev2-null-auth-03
>
> Abstract:
>   This document introduces the NULL Authentication Method for the IKEv2
>   Protocol.  This method provides a way to omit peer authentication in
>   the IKEv2.  It may be used to preserve anonymity of or in the
>   situations, where no trust relationship exists between the parties.
>
>
>
>
> Please note that it may take a couple of minutes from the time of 
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
> 


From nobody Tue Sep  2 15:04:49 2014
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902DD1A0720; Tue,  2 Sep 2014 15:04:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6XJZN0hj5mw; Tue,  2 Sep 2014 15:04:45 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CA91A0792; Tue,  2 Sep 2014 15:04:43 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.2.p5
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140902220443.1541.40721.idtracker@ietfa.amsl.com>
Date: Tue, 02 Sep 2014 15:04:43 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/K0fi1wd7RAdQivBq4C3yPCdhvh8
Cc: ipsecme mailing list <ipsec@ietf.org>, ipsecme chair <ipsecme-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [IPsec] Protocol Action: 'IKEv2 Fragmentation' to Proposed Standard (draft-ietf-ipsecme-ikev2-fragmentation-10.txt)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Sep 2014 22:04:48 -0000

The IESG has approved the following document:
- 'IKEv2 Fragmentation'
  (draft-ietf-ipsecme-ikev2-fragmentation-10.txt) as Proposed Standard

This document is the product of the IP Security Maintenance and
Extensions Working Group.

The IESG contact persons are Kathleen Moriarty and Stephen Farrell.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/




Technical Summary

    This document describes a method to avoid IP fragmentation in large 
    IKEv2 messages. It shows how to perform fragmentation in IKEv2 
    itself, replacing them by series of smaller messages.
    This allows IKEv2 messages to traverse network devices that don't 
    allow IP fragments to pass through.

    Given that this is a protocol extension, it is meant to be a 
    Proposed Standard.

Working Group Summary

    Was there anything in the WG process that is worth noting?

    The WG discussion of the document was fairly good, with about 
    average participation (which for the IPsecME WG means "the chairs 
    had to beg a bit for more participants, but we then got them"). We 
    also got a "TSVDIR-ish review" of the draft, which got good 
    discussion on the list. There was a reasonable amount of give-and-
    take, and the WG Last Call was uncontentious. A significant point 
    was brought up during IETF Last Call, and was added to the Security
    Considerations as a result of the SecDir review.

    A few issues came up during the first IESG review.  Another series 
    of edits occurred along with detailed reviews by a couple of area 
    experts.  The edited draft went back through WG last call and is 
    ready for IESG review again.

Document Quality

   Are there existing implementations of the protocol?  Have a 
   significant number of vendors indicated their plan to
   implement the specification?  Are there any reviewers that
   merit special mention as having done a thorough review,
   e.g., one that resulted in important changes or a
   conclusion that the document had no substantive issues?  If
   there was a MIB Doctor, Media Type, or other Expert Review,
   what was its course (briefly)?  In the case of a Media Type
   Review, on what date was the request posted?

Personnel

   Paul Hoffman (IPsecME WG co-chair) is the document shepherd and Kathleen Moriarty is the
   responsible AD.


From nobody Thu Sep  4 08:10:32 2014
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5561A8915; Thu,  4 Sep 2014 08:10:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9EMw7PzjmMq; Thu,  4 Sep 2014 08:10:26 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFAA1A8907; Thu,  4 Sep 2014 08:10:10 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.2.p6
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140904151010.28272.7982.idtracker@ietfa.amsl.com>
Date: Thu, 04 Sep 2014 08:10:10 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/AQtq7P-EbGZx6t29azQXhc25UeE
Cc: ipsecme mailing list <ipsec@ietf.org>, ipsecme chair <ipsecme-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [IPsec] CORRECTED Protocol Action: 'IKEv2 Fragmentation' to Proposed Standard (draft-ietf-ipsecme-ikev2-fragmentation-10.txt)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Sep 2014 15:10:28 -0000

The IESG has approved the following document:
- 'IKEv2 Fragmentation'
  (draft-ietf-ipsecme-ikev2-fragmentation-10.txt) as Proposed Standard

This document is the product of the IP Security Maintenance and
Extensions Working Group.

The IESG contact persons are Kathleen Moriarty and Stephen Farrell.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/




Technical Summary

    This document describes a method to avoid IP fragmentation in large 
    IKEv2 messages. It shows how to perform fragmentation in IKEv2 
    itself, replacing them by series of smaller messages.
    This allows IKEv2 messages to traverse network devices that don't 
    allow IP fragments to pass through.

    Given that this is a protocol extension, it is meant to be a 
    Proposed Standard.

Working Group Summary

    Was there anything in the WG process that is worth noting?

    The WG discussion of the document was fairly good, with about 
    average participation (which for the IPsecME WG means "the chairs 
    had to beg a bit for more participants, but we then got them"). We 
    also got a "TSVDIR-ish review" of the draft, which got good 
    discussion on the list. There was a reasonable amount of give-and-
    take, and the WG Last Call was uncontentious. A significant point 
    was brought up during IETF Last Call, and was added to the Security
    Considerations as a result of the SecDir review.

    A few issues came up during the first IESG review.  Another series 
    of edits occurred along with detailed reviews by a couple of area 
    experts.  The edited draft went back through WG last call and is 
    ready for IESG review again.

Document Quality

  The draft had working group consensus and there is one implementation 
  to date.

  The WG discussion of the document was fairly good, with about average
  participation (which for the IPsecME WG means "the chairs had to beg a 
  bit for more participants, but we then got them"). We also got a 
  "TSVDIR-ish review" of the draft, which got good discussion on the
  list. There was a reasonable amount of give-and-take, and the WG Last 
  Call was uncontentious. A significant point was brought up during IETF 
  Last Call, and was added to the Security Considerations."

Personnel

   Paul Hoffman (IPsecME WG co-chair) is the document shepherd and Kathleen Moriarty is the
   responsible AD.


From nobody Fri Sep  5 06:05:58 2014
Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D531A06B0 for <ipsec@ietfa.amsl.com>; Fri,  5 Sep 2014 06:05:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.139
X-Spam-Level: *
X-Spam-Status: No, score=1.139 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boJbxf2IMmYk for <ipsec@ietfa.amsl.com>; Fri,  5 Sep 2014 06:05:45 -0700 (PDT)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F7411A016A for <ipsec@ietf.org>; Fri,  5 Sep 2014 06:05:44 -0700 (PDT)
Received: by mail-lb0-f174.google.com with SMTP id n15so3911498lbi.33 for <ipsec@ietf.org>; Fri, 05 Sep 2014 06:05:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=hKoHlGjunmfNO12IIyzPHC3N8sVED3t7fvc+EmguTBY=; b=mmIoYsOM9Mmj5Y/YE+a9nox/Gl7Cxf0VsROjBi5mUXzqpevdXX3qGsPZ/EzfneVEi2 TNufZdbWRIFQ4SYjxZquNeOSu4xN2oqGGQUytFe7AT2dLtsdn6teSZRr1XJkE5nUqKb5 bYRSSv8dECmmPVJim0YNT0nFywKXeWcngXE8I/vGkC3kOZBbhrRIm4RJrVID/RAMfGln PfCHZZ4BUU3oi8Hut24bWRNQcDssUnQILHZlR8azvboZHwDKk4T8Wk1POcz6e1AtYByV vkNUDK7iBys31InUmQpA9PWECrOIz45QxxUxxshmYqOQnAOoJmwLy98TC9Sd6VXs6q8w tSNA==
X-Received: by 10.152.28.230 with SMTP id e6mr11765056lah.62.1409922342091; Fri, 05 Sep 2014 06:05:42 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id yx5sm716615lbb.35.2014.09.05.06.05.40 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 05 Sep 2014 06:05:41 -0700 (PDT)
Message-ID: <DC2FED9C253548E5875C4E5CCCFD40D0@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Tero Kivinen" <kivinen@iki.fi>
References: <F68C660364DABE41AF4617F517EF548411707BE2@ESESSMB309.ericsson.se><21493.55390.157248.181030@fireball.kivinen.iki.fi><C949D5C9077942ACA31105FE4156154E@buildpc> <21504.31762.454252.961126@fireball.kivinen.iki.fi>
Date: Fri, 5 Sep 2014 17:05:42 +0400
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/S-m7cVngzL1MIA9XR6p_uggWI7E
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Typos in draft-kivinen-ipsecme-ikev2-rfc5996bis-04
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Sep 2014 13:05:49 -0000

Section 2.23, 4th bullet:

   o  The recipient of either the NAT_DETECTION_SOURCE_IP or
      NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied
      value to a SHA-1 hash of the SPIs, source or recipient IP address
      (respectively), address, and port, and if they don't match, it
      SHOULD enable NAT traversal.  [...]

It seems that there is an extra "address". Shouldn't it be:


   o  The recipient of either the NAT_DETECTION_SOURCE_IP or
      NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied
      value to a SHA-1 hash of the SPIs, source or recipient IP address and 
port
      (respectively), and if they don't match, it
      SHOULD enable NAT traversal.  [...]

or

   o  The recipient of either the NAT_DETECTION_SOURCE_IP or
      NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied
      value to a SHA-1 hash of the SPIs, source or recipient (respectively)
      IP address and port, and if they don't match, it
      SHOULD enable NAT traversal.  [...]



From nobody Sun Sep  7 11:53:16 2014
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3A11A069F for <ipsec@ietfa.amsl.com>; Sun,  7 Sep 2014 11:53:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.424
X-Spam-Level: *
X-Spam-Status: No, score=1.424 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOKxax6vLGR0 for <ipsec@ietfa.amsl.com>; Sun,  7 Sep 2014 11:53:14 -0700 (PDT)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EC9B1A069B for <ipsec@ietf.org>; Sun,  7 Sep 2014 11:53:14 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id y10so197292wgg.15 for <ipsec@ietf.org>; Sun, 07 Sep 2014 11:53:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=5OyMQZ+SEnhxUBl7G2tlZySoMf6lD+w+c/EriWhszUk=; b=ebA8SPO/YQgsjmjssFG4B3NuM3HUuzL6i7VRfuKxLRHo4F7q2Uo+EjvjwEIramRHwh AihqjpSsv/RK4RVDvQrqczpP0Tf3D1XxHg1NTpKGLfvMDLypxiY/NM3tlRfrFcVaFLwq A+K8d/0V4Ii8ItGAZEwxBgtcL+W4pbyty7AnthVXAIahPIj+PG7p6OUz/HB1cm/s2u55 ymgqm361Xh8ivGVDToNF1sAiR4MkUTT0l8rld39Ys3HipsVpyVHKRWokYThfg+xmlOHC 3M2TfkbozbJr2fMZRNL1/jCo08pN1zG8zNgDEYjL/RoYGpeHfJb0/KlhzVroqU3pMv+c 429Q==
X-Received: by 10.180.101.129 with SMTP id fg1mr17243903wib.20.1410115992802;  Sun, 07 Sep 2014 11:53:12 -0700 (PDT)
Received: from [10.0.0.9] (bzq-79-177-135-86.red.bezeqint.net. [79.177.135.86]) by mx.google.com with ESMTPSA id u7sm9123002wif.7.2014.09.07.11.53.11 for <ipsec@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Sep 2014 11:53:12 -0700 (PDT)
Message-ID: <540CA995.6050203@gmail.com>
Date: Sun, 07 Sep 2014 21:53:09 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: ipsec <ipsec@ietf.org>
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/06N2nYy8RKGTVuWPNxpjpelqYII
Subject: [IPsec] Calls for adoption
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Sep 2014 18:53:15 -0000

<html style="direction: ltr;">
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    <style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
  </head>
  <body style="direction: ltr;" bidimailui-charset-is-forced="true"
    text="#000000" bgcolor="#FFFFFF">
    Hi ipsecme folks,<br>
    <br>
    At the Toronto meeting we reviewed 3 documents. We would like to
    know if the group is interested in adopting one or more of them as
    WG documents. We plan to issue separate calls for adoption for each
    one, with a duration of one work-week (5 days) each, starting today.<br>
    <br>
    Thanks,<br>
        Yaron<br>
  </body>
</html>


From nobody Sun Sep  7 11:53:44 2014
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25711A06A5 for <ipsec@ietfa.amsl.com>; Sun,  7 Sep 2014 11:53:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dly86feRu0Z for <ipsec@ietfa.amsl.com>; Sun,  7 Sep 2014 11:53:43 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46F81A06A4 for <ipsec@ietf.org>; Sun,  7 Sep 2014 11:53:42 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id hi2so1601759wib.10 for <ipsec@ietf.org>; Sun, 07 Sep 2014 11:53:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=JnrX4HKzkLrstMrJB+zZmre49KcfJ2MWRcgUXaM1vvw=; b=gR4xeNu+Qr3Lf/uAXxs0ieiyln8BXedMJK4/4XZWpHabg1Urr47GuU3v7k9ueWgGCe Ji4hidD+LFkaexwlLiTFd18WOIFvDIIGlrQeLINoani8jy7h5MVuwboZc7SQ1ov0dFrx d7zcoanIweoyPRRUZheRvE1oSAJypaVhvBVJIFv/h897ij8UyX64D6QTG6d+kggPXU4/ z+nj2Fyf9N23J4mIaXxI8tDiMc0ZmIkV0gqJMWpL+r7Ro53XnGPRoBurcZU3QadGnQti hHgH01l3UuaLUn7Zf2iYLJfTMeiyDso0qk7XAhgvA0daPrhM9WAXH3PGrESUtaeYGMqA t41g==
X-Received: by 10.180.91.70 with SMTP id cc6mr17601153wib.66.1410116021331; Sun, 07 Sep 2014 11:53:41 -0700 (PDT)
Received: from [10.0.0.9] (bzq-79-177-135-86.red.bezeqint.net. [79.177.135.86]) by mx.google.com with ESMTPSA id gk17sm9238308wic.16.2014.09.07.11.53.40 for <ipsec@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Sep 2014 11:53:40 -0700 (PDT)
Message-ID: <540CA9B2.3090807@gmail.com>
Date: Sun, 07 Sep 2014 21:53:38 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: ipsec <ipsec@ietf.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/7oDHl3kkW8suM7EUvXkrLpceGKw
Subject: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Sep 2014 18:53:44 -0000

Dear working group,

This is a call for adopting draft-smyslov-ipsecme-ikev2-null-auth as a 
WG document. Please respond to this mail with a Yes or No and a short 
rationale, at latest by Friday Sep. 12.

Thanks,
	Yaron


From nobody Sun Sep  7 23:27:31 2014
Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2F81A0056 for <ipsec@ietfa.amsl.com>; Sun,  7 Sep 2014 23:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMWC4wbCnZXx for <ipsec@ietfa.amsl.com>; Sun,  7 Sep 2014 23:27:28 -0700 (PDT)
Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CB781A6F1F for <ipsec@ietf.org>; Sun,  7 Sep 2014 23:27:28 -0700 (PDT)
Received: by mail-lb0-f181.google.com with SMTP id z11so2958893lbi.12 for <ipsec@ietf.org>; Sun, 07 Sep 2014 23:27:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=B3QTjdpaAFgyrMLaMLfMkC8ECDW/O3L2D+VyTkL5jY4=; b=lYL56PF20REid6EwfjY4irrv0kNajAfQCGzvcB80MAg1bLVjtB+Tu6uBE6+FxwEEUk oljtPI96epcdqq74O5dUSVs3DuET48gUl6PxRr9FxhnvFl4438lDiC+rsXqfX3G+Vhlp vJgYwkOMEKzKqjfDCTmIAJdmnPyANodB0xVK9LRv6wC3ACIBiAVKdFrDmC4mMlqvd6ly 9JWHJM+eZMOFxY7PfpVXRmCkSGBu+uaaq24u2P8AZcwCnabSRdHv41qmkoInIMJVtsjm N/iP0ea3VCyqvfuA95kLRHgdHqd0SrV0E75n7G2Qe0QeiglGvh56F5tDp6bkO2iWg7u9 piRg==
X-Received: by 10.112.17.2 with SMTP id k2mr8478148lbd.28.1410157646419; Sun, 07 Sep 2014 23:27:26 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id xy9sm3241605lbb.6.2014.09.07.23.27.25 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 07 Sep 2014 23:27:25 -0700 (PDT)
Message-ID: <DCC36F8DE78A4E5280A9977B4CAC144A@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Yaron Sheffer" <yaronf.ietf@gmail.com>, "ipsec" <ipsec@ietf.org>
References: <540CA9B2.3090807@gmail.com>
Date: Mon, 8 Sep 2014 10:27:25 +0400
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/d12ifIgsLfactTA6aFI4KL6tu9s
Subject: Re: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2Protocol
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Sep 2014 06:27:30 -0000

Yes.

Obviously, as the author of the document I can see its value,
which is describet in the document itself.
And I think it's better to standardize it with
more people involved, than as individual submission.

Regards,
Valery.

----- Original Message ----- 
From: "Yaron Sheffer" <yaronf.ietf@gmail.com>
To: "ipsec" <ipsec@ietf.org>
Sent: Sunday, September 07, 2014 10:53 PM
Subject: [IPsec] Call for adoption: The NULL Authentication Method in 
IKEv2Protocol


> Dear working group,
>
> This is a call for adopting draft-smyslov-ipsecme-ikev2-null-auth as a WG 
> document. Please respond to this mail with a Yes or No and a short 
> rationale, at latest by Friday Sep. 12.
>
> Thanks,
> Yaron
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec 


From nobody Mon Sep  8 06:04:34 2014
Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5321A87D4 for <ipsec@ietfa.amsl.com>; Mon,  8 Sep 2014 06:04:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.753
X-Spam-Level: 
X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnwYfUlnxFGL for <ipsec@ietfa.amsl.com>; Mon,  8 Sep 2014 06:04:31 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2034B1A87CE for <ipsec@ietf.org>; Mon,  8 Sep 2014 06:04:30 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2BD8280416; Mon,  8 Sep 2014 09:04:27 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1410181467; bh=30PofIZ0wA5Vfgpl43lmx5Se5FXRWFklqNIVu0dikfI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=JdiHMq7RzoZBwBrSjaI0Q4RVCcivp7aQn1a0Yw8nLINrV8UumuE6KVeuV+AsI1Z3c O5/JB63vPae9IPNPhbul+q/T/LqPGW0zp5cC5in/8Wc5l2WCwghEbae1e2DiDGiyQ2 mhBFnXIvhJmsSfcL/r44sMRgby72teCrZ6c3t+UI=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s88D4QIq003224; Mon, 8 Sep 2014 09:04:26 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Mon, 8 Sep 2014 09:04:26 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
In-Reply-To: <540CA9B2.3090807@gmail.com>
Message-ID: <alpine.LFD.2.10.1409080902080.31411@bofh.nohats.ca>
References: <540CA9B2.3090807@gmail.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Rbq8tre4WLoyIANXEYwP6ZXhNYA
Cc: ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Sep 2014 13:04:33 -0000

On Sun, 7 Sep 2014, Yaron Sheffer wrote:

> Subject: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2
>     Protocol
> 
> Dear working group,
>
> This is a call for adopting draft-smyslov-ipsecme-ikev2-null-auth as a WG 
> document. Please respond to this mail with a Yes or No and a short rationale, 
> at latest by Friday Sep. 12.

Yes. This feature is very useful for opportunistic scenario's to defend
against pervasive monitoring with no IPsec configuration needed on the
client side. We are implementing this and it is important to
interoperate with other implementations.

Paul


From nobody Mon Sep  8 07:54:14 2014
Return-Path: <Paul_Koning@dell.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08C01A8847 for <ipsec@ietfa.amsl.com>; Mon,  8 Sep 2014 07:54:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.653
X-Spam-Level: 
X-Spam-Status: No, score=-8.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoxAhY0BzvCn for <ipsec@ietfa.amsl.com>; Mon,  8 Sep 2014 07:54:11 -0700 (PDT)
Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60D081A8842 for <ipsec@ietf.org>; Mon,  8 Sep 2014 07:54:11 -0700 (PDT)
DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:Return-Path; b=fbZ8QqQud/V/BNtjtX3mTrsyyDTt+KmpZV5bU5uHzbCuNWzQxgi9kA75 fLh8t/5Ps7SsEaOhbfYObIVmAjXAWFFIvATbH1sr7e/HQqEUx7XBCieI0 aQW3IGJ5QN8eNhQ/lOxUI7Xysn9iR4MXm0BGtnS6xSsrM6jOhZWm/R9J2 o=;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1410188051; x=1441724051; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jvoV54u3o16ObN9umwSJXfU5P7EYZlBvVGjDRXyC6Hk=; b=VfoREBkPJa4bzH99aZ/ZEdJoW0kAB2czxSqF+wRFjHsYL6o14fO2oHqz f00itYEQVfM6ygquFBlmd0rF28tR0vYHnAwSA9aNHfkv6Y8tz7HYeVNmw MMJfQs6SDhrQxoS7CwCA00PDsLrI7uXiiHx2G7CwtIiB/aVUMSJT1PPyg Y=;
X-LoopCount0: from 10.170.28.39
X-IronPort-AV: E=Sophos;i="5.04,486,1406610000"; d="scan'208";a="564034293"
From: <Paul_Koning@Dell.com>
To: <yaronf.ietf@gmail.com>
Thread-Topic: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol
Thread-Index: AQHPy3S+RQfjeqJSdUuFetBAvZq/+g==
Date: Mon, 8 Sep 2014 14:54:09 +0000
Message-ID: <BE175F90-68B6-4731-B32E-BA9EF3F3BAD8@dell.com>
References: <540CA9B2.3090807@gmail.com>
In-Reply-To: <540CA9B2.3090807@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.152.216.26]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <397F1DF8D33F774FB7C8650E5B8C48F7@dell.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/CcbUhRF6FJ7DVoqYOdLGoAqEvdE
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Sep 2014 14:54:13 -0000

On Sep 7, 2014, at 2:53 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

> Dear working group,
>=20
> This is a call for adopting draft-smyslov-ipsecme-ikev2-null-auth as a WG=
 document. Please respond to this mail with a Yes or No and a short rationa=
le, at latest by Friday Sep. 12.

Maybe.

I understand and support the rationale for this draft. =20

The Security Considerations seems to be inadequate.  Whenever possible, rea=
l authentication should be used.  So the Security Considerations should exp=
licitly and strongly emphasize that, and recommend that products that incor=
porate Null authentication should strive to avoid its use whenever possible=
, and steer users away from its use when they can.

A related question: does the use of Null authentication open up the Bellovi=
n attack?  It seems that it would.  If so, my answer changes to =93NO=94.

	paul


From nobody Mon Sep  8 10:12:27 2014
Return-Path: <grbartle@cisco.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6F41A8984 for <ipsec@ietfa.amsl.com>; Mon,  8 Sep 2014 10:12:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.153
X-Spam-Level: 
X-Spam-Status: No, score=-16.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7xEYjQW-ED7 for <ipsec@ietfa.amsl.com>; Mon,  8 Sep 2014 10:12:11 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B59B01A894D for <ipsec@ietf.org>; Mon,  8 Sep 2014 10:10:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6891; q=dns/txt; s=iport; t=1410196209; x=1411405809; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=7kY+TeeWba2vkzTjrOcoQjyBQDkB9Cz5LCS9LPPlRw0=; b=FYsnYFbq5QqFO0YVXbn6P3+CQyzYrWFSKIe+mNGWqZ9mtVwsTyT2QCwb yUgBU59RRA6KvLuZ44rxAt6Xc9yBFUuo1gawPuOl6k0Nlmuxzfb1PqHvC xBknHxHOH4ZIThH65lC5IeWIWQf1idY5IbldPb27yclS/CE+yy71Bhj2y U=;
X-Files: smime.p7s : 3708
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AicFACXiDVStJA2B/2dsb2JhbABQCYJqI1NXBMlnCodMAYEVFniEAwEBAQQBAQEaURcEAgEIDgMEAQEvAh8GCx0IAgQBEg6IIAMRAQy1CQ2GXQETBI0ggVIKAQE0IgaERgWPK4IVggaBSoVSghCOc4Y5g2FsgQ85gQcBAQE
X-IronPort-AV: E=Sophos;i="5.04,486,1406592000";  d="p7s'?scan'208";a="75998391"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-4.cisco.com with ESMTP; 08 Sep 2014 17:10:08 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s88HA8uS019535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Sep 2014 17:10:09 GMT
Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Mon, 8 Sep 2014 12:10:08 -0500
From: "Graham Bartlett (grbartle)" <grbartle@cisco.com>
To: Valery Smyslov <svanru@gmail.com>, Yaron Sheffer <yaronf.ietf@gmail.com>,  ipsec <ipsec@ietf.org>
Thread-Topic: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2Protocol
Thread-Index: AQHPyy4DFcwTtQ+4VEqN7XrYpOOjUZv33bCA
Date: Mon, 8 Sep 2014 17:10:07 +0000
Message-ID: <D033575C.2C348%grbartle@cisco.com>
References: <540CA9B2.3090807@gmail.com> <DCC36F8DE78A4E5280A9977B4CAC144A@buildpc>
In-Reply-To: <DCC36F8DE78A4E5280A9977B4CAC144A@buildpc>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
x-originating-ip: [10.55.146.101]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3493044605_9956769"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/n_tQBwsTIHJXCvN6YTBcAn7zHEc
Subject: Re: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2Protocol
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Sep 2014 17:12:23 -0000

--B_3493044605_9956769
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Hi Valery



I have one Q.

If endpoint receives a request to create an unauthenticated IKE SA
from the IP address, which is configured on the endpoint to be
authenticated, the request SHOULD be rejected.


Why is this not MUST be rejected ? Otherwise an attacker could trick the
responder into revealing their identity (maybe some words around this
also?).

Thanks

Graham


On 08/09/2014 07:27, "Valery Smyslov" <svanru@gmail.com> wrote:

>Yes.
>
>Obviously, as the author of the document I can see its value,
>which is describet in the document itself.
>And I think it's better to standardize it with
>more people involved, than as individual submission.
>
>Regards,
>Valery.
>
>----- Original Message -----
>From: "Yaron Sheffer" <yaronf.ietf@gmail.com>
>To: "ipsec" <ipsec@ietf.org>
>Sent: Sunday, September 07, 2014 10:53 PM
>Subject: [IPsec] Call for adoption: The NULL Authentication Method in
>IKEv2Protocol
>
>
>> Dear working group,
>>
>> This is a call for adopting draft-smyslov-ipsecme-ikev2-null-auth as a
>>WG 
>> document. Please respond to this mail with a Yes or No and a short
>> rationale, at latest by Friday Sep. 12.
>>
>> Thanks,
>> Yaron
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>
>_______________________________________________
>IPsec mailing list
>IPsec@ietf.org
>https://www.ietf.org/mailman/listinfo/ipsec

--B_3493044605_9956769
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIOeAYJKoZIhvcNAQcCoIIOaTCCDmUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgggw+MIIEpzCCA4+gAwIBAgIQZmBP5MZi1b5ckUheWh5wbTANBgkqhkiG9w0BAQUFADBU
MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xv
YmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMB4XDTE0MDEyNTIyNDE0OFoXDTE2MDYw
MzExMDA1OFowQDEbMBkGA1UEAwwSZ3JiYXJ0bGVAY2lzY28uY29tMSEwHwYJKoZIhvcNAQkB
FhJncmJhcnRsZUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCq
YhYxolKrFoPfXuZTQdAiQVFg14EvWwIEMyXxhfH2RiwOSJRSsUVmTNYG8HdeSf0JdzjAMh9p
ODgxLC90Q1nbLyBqmEAKElWTasAnATKBCD7aLhce+25cznTT4FDpJsvvU2lZFPWXSLQm3bNR
+mEDP6pd8zR1ItOKBlNmGtwypUUvi4KrKRPzx1cSgVTN0Xocj4fC5N8Rj3tOqOns+EHOX4Rw
oy/rebHjQyv1cRr6FyGhRuz24hPv8mAGr/iF0cMphAsujaGKyAo+tA05K3nI0fdoeCx2wdEs
vo8jIeeZVii07b3K9+VdJQmerVKJyMfQT6gLkyuassY/5aXlglNxAgMBAAGjggGHMIIBgzAO
BgNVHQ8BAf8EBAMCBaAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYm
aHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wHQYDVR0RBBYwFIESZ3Ji
YXJ0bGVAY2lzY28uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF
BwMEMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3Nw
ZXJzb25hbHNpZ24xZzIuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDov
L3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24xZzIuY3J0MB0G
A1UdDgQWBBRBHvZ1Aur9AFGMEId10iH6yeUX3jAfBgNVHSMEGDAWgBTsrJjMJ3KTz1YyzSPH
nY1FhfQiAzANBgkqhkiG9w0BAQUFAAOCAQEAdhq5YZv5ZCu0/HdQF1S3f+quesVc39HKv+Fe
2rmKuJcxfGOFZGpKhJDa1+sFeN/T+e2e6UJ0Yy90GLqi5U1fioD3XRhsFiVOh7CbJQESF2Xx
U1bhdutZFh6Ythe28iRPY6HQjJ/7ke5IQBWvLnAbCIzgy0GgZB9Vj+a2z6bzmfR6KAuLaMqM
vahvJ0w+DeHMEOVnVzCdZzHMaEOXZHw/uZj5/hGvkp2C0rH/LhGunfAPX12WhVQSsgxWJhaF
8D49Ymrt7PWBsLokx06/15XwY2ogBmfLmeN/WhMy5HUiLn3EnzwF+RK2MStCDpP5AWzdnrTR
tM43+AJrHwoI7H+C9DCCBBYwggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUA
MFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdS
b290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcN
MTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1z
YTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGjx0+LH0uRqeZCHrYQ7KN3QuahfxY8
fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqDlin3HracDqMRgwrknWuFeqxh
N2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQBhcaJA2ucABbUVTHDTxi
7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+OhtnAhrgzrsd4oAy
qgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7upoxvV09Fsf7h
DeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUdIAAw
NDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w
MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAf
BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7un
yEtmt9Ia7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDu
vg/OZ0gILDFIa9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVU
m5V1tW3XuYNg6SbtcDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVg
wb/j/kplOa13nshhc8zULVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5ui
B8TZ0s327g44Ylc6dgKgYelNn9RLYjNETX8OIJZlr0tFYpcYrDCCA3UwggJdoAMCAQICCwQA
AAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i
YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJv
b3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJCRTEZ
MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS
R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7m
mY3Oo+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsur
HExwB6E9CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8G
PIhpWypNxadUuGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounI
Cjjr8iQTT3NUkxOFOhu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjI
GSvRRqpI1mQq14M0/ywqwWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8B
Af8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8
/UswDQYJKoZIhvcNAQEFBQADggEBANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16q
EUi25Qijs8o9YU3TRgmzPsOg42NVG/K676054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeY
BN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8suWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUM
HaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRWMZXQZ4mFK/lspl1GnQyqguSZUd1wt9tW
PWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY24GzBBzFH6SAbxUgyd4MiAod1mZV
4vxIySkmaeAxggH+MIIB+gIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT
aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzIC
EGZgT+TGYtW+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgioIY
VXF7EUSLDagdFVZx98jx3/zKShlPJcVDbochKH4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNMTQwOTA4MTcxMDA1WjANBgkqhkiG9w0BAQEFAASCAQBWCib8
FFBeUHk1Sz0QSGSUwBJYGzobFwXZgUBQOgrCalHkKlnpcClFoSrS8jql/WV+KZ+De7ouxBg9
Ptnnhq8RIa2Phq9rVL6rfm9tAk1RUc3HIwL2gORMfLYPLcaAzVuzLYXci7DAtJXqWPp2/tMy
QTgwiIiD901PoGqzJjW20pkdyzEVsHA8YAI5fwmy+TOxZYqP80aeGmMXzs+VUcb0qZ9ubHHj
Y7TN1AZ1u0gjDefrONqxyznoBe2Y1W+cmqcO7b3VyDHEgNC9yL7KQwud2Fju5bMerSVMSHoo
hh8p4jUF5j9JpYMxnawFOa3KdcvWmYEEOSePHiZdCYUFMqUp

--B_3493044605_9956769--


From nobody Mon Sep  8 11:17:52 2014
Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C001A0263 for <ipsec@ietfa.amsl.com>; Mon,  8 Sep 2014 11:17:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.652
X-Spam-Level: 
X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3QyUA1h96ls for <ipsec@ietfa.amsl.com>; Mon,  8 Sep 2014 11:17:47 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B81F61A0262 for <ipsec@ietf.org>; Mon,  8 Sep 2014 11:17:47 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 313BE80416; Mon,  8 Sep 2014 14:17:46 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1410200266; bh=+jXUuWDfZ/IBCQsAdT7N8g3pH2ypboe/2C2QJcJYLDo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=PalyhIxZotprYYZEgoTwQj7+eeAVzbBqgbmniUbGSYN1FMXqI8MEN1GzR6TAmGkuu 6Hl2bgR4ptRKoqqBv7RgTTkJPI7nqcIAeNV6A+TK9Uh1o6F8Sw36SAS6NAEBuzF36+ Z6jqI/cEimfeDPpnZx7jR5la+A+7RNhZRktYUsJA=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s88IHjZm025568; Mon, 8 Sep 2014 14:17:45 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Mon, 8 Sep 2014 14:17:44 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Paul_Koning@Dell.com
In-Reply-To: <BE175F90-68B6-4731-B32E-BA9EF3F3BAD8@dell.com>
Message-ID: <alpine.LFD.2.10.1409081412050.23553@bofh.nohats.ca>
References: <540CA9B2.3090807@gmail.com> <BE175F90-68B6-4731-B32E-BA9EF3F3BAD8@dell.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/3V87BY5DQKPReX8HgU_FU9Rd9Aw
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Sep 2014 18:17:49 -0000

On Mon, 8 Sep 2014, Paul_Koning@Dell.com wrote:

> Maybe.
>
> I understand and support the rationale for this draft.
>
> The Security Considerations seems to be inadequate.  Whenever possible, real authentication should be used.  So the Security Considerations should explicitly and strongly emphasize that, and recommend that products that incorporate Null authentication should strive to avoid its use whenever possible, and steer users away from its use when they can.

I think that is better formulated as "use null authentication only if the
alternative is to send plaintext".

> A related question: does the use of Null authentication open up the Bellovin attack?  It seems that it would.  If so, my answer changes to �NO�.

I find multiple references to a "Bellovin attack", but all seem to be active
attacks. Unauthenticated connections are not protected from active attacks.
However, with IKE one peer can authenticate the other without letting itself
be authenticated - like TLS clients. That _is_ a protection against
active attacks while still using null auth in one direction.

Paul


From nobody Mon Sep  8 11:37:47 2014
Return-Path: <Paul_Koning@dell.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058EE1A02D0 for <ipsec@ietfa.amsl.com>; Mon,  8 Sep 2014 11:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.953
X-Spam-Level: 
X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEhwRljG66_P for <ipsec@ietfa.amsl.com>; Mon,  8 Sep 2014 11:37:42 -0700 (PDT)
Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25BBA1A02BC for <ipsec@ietf.org>; Mon,  8 Sep 2014 11:37:41 -0700 (PDT)
DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:Return-Path; b=DeMIf5lhbPKhD2kcIkZH76TqyKb0VPo527wQAS/hwrJ7Hb0goleTPb4Z h4KJswpbLw4EP8aEcyyGMV7iQP8pKxE8FGoPzDjRvR7uLIHtPHgNIrfox OB9M6EivkFb6xQEKuLgQaTZ6EtTSpqpImpyLfE4GmVb3oi6sKRJls2ALD Y=;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1410201462; x=1441737462; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0AHYa1yVVFRMYd1WOFjMByc2xA9I8vIg6fHVLyzqU4k=; b=kWEqgZEO+ey/gFa+2bx6bxQz/AT3aMALNuEdIt1BA0cQT6B1JwqmMatC wvdbUAMo5N7cxxhUzBvSMtT19XdlEyDKRw1raUkNW0JA5g+G+eiJIKgJC CfK0T6UiIJdusdo157tRRLiAhk9PgZRlLYAU9qF1VNI/YQUjIlAlKwkZO A=;
X-LoopCount0: from 10.170.28.41
X-IronPort-AV: E=Sophos;i="5.04,487,1406610000"; d="scan'208";a="576769739"
From: <Paul_Koning@Dell.com>
To: <paul@nohats.ca>
Thread-Topic: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol
Thread-Index: AQHPy3S+pO6kHNlTNUC0lCro6ItLEpv330YAgAAFiwA=
Date: Mon, 8 Sep 2014 18:37:35 +0000
Message-ID: <7C9AB479-042F-4039-9F02-4483F9C8385C@dell.com>
References: <540CA9B2.3090807@gmail.com> <BE175F90-68B6-4731-B32E-BA9EF3F3BAD8@dell.com> <alpine.LFD.2.10.1409081412050.23553@bofh.nohats.ca>
In-Reply-To: <alpine.LFD.2.10.1409081412050.23553@bofh.nohats.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.152.216.26]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <8EB4CEB4498ECF4C8C90727ADDED4195@dell.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/oKmyTBzX6UM5yOYT_65tWpH47aw
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Sep 2014 18:37:45 -0000

On Sep 8, 2014, at 2:17 PM, Paul Wouters <paul@nohats.ca> wrote:

> On Mon, 8 Sep 2014, Paul_Koning@Dell.com wrote:
>=20
>> Maybe.
>>=20
>> I understand and support the rationale for this draft.
>>=20
>> The Security Considerations seems to be inadequate.  Whenever possible, =
real authentication should be used.  So the Security Considerations should =
explicitly and strongly emphasize that, and recommend that products that in=
corporate Null authentication should strive to avoid its use whenever possi=
ble, and steer users away from its use when they can.
>=20
> I think that is better formulated as "use null authentication only if the
> alternative is to send plaintext=94.

That is a very good way to state it.  Thanks.

>> A related question: does the use of Null authentication open up the Bell=
ovin attack?  It seems that it would.  If so, my answer changes to =93NO=94=
.
>=20
> I find multiple references to a "Bellovin attack", but all seem to be act=
ive
> attacks. Unauthenticated connections are not protected from active attack=
s.
> However, with IKE one peer can authenticate the other without letting its=
elf
> be authenticated - like TLS clients. That _is_ a protection against
> active attacks while still using null auth in one direction.

I was referring to https://www.cs.columbia.edu/~smb/papers/badesp.pdf .

The existing security considerations section refers to a man in the middle =
attack.  Bellovin=92s attack is not a man in the middle attack.  It does no=
t require being able to modify the data stream under attack at all.  For th=
at reason, it is likely to be easier to execute and harder to detect. =20

In any event, if we=92re going to have a new IPSec mode that weakens the no=
rmal properties of IPSec, we need to be very explicit and very detailed abo=
ut what precisely you lose by using this mode.  I would expect a security c=
onsiderations section that takes up at least half the total page count of t=
he document, as opposed to just a third of a page as it is right now.

For example, right now the security considerations section does NOT say tha=
t =93Unauthenticated connections are not protected from active attacks=94. =
 It only says that they are not protected from man in the middle attacks.=20

	paul


From nobody Mon Sep  8 11:53:16 2014
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975A31A0317 for <ipsec@ietfa.amsl.com>; Mon,  8 Sep 2014 11:53:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7gsbaMJod3V for <ipsec@ietfa.amsl.com>; Mon,  8 Sep 2014 11:53:13 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0171E1A02D4 for <ipsec@ietf.org>; Mon,  8 Sep 2014 11:53:12 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id k14so1203467wgh.24 for <ipsec@ietf.org>; Mon, 08 Sep 2014 11:53:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Q93U6PzRombG1UzTF6kQ0ME1X367GDlafAKUXHvyc8E=; b=MFAL+jYNbzzvsaMU4wW8n7VwkBUUygK3P5vXmVskF+ftuaITgOsnbRD3ixxq1fcqb0 pZSzoEMU/ulpsCNE7ydu6cfP0oD4GpckGnSYwV6sEpmKNw2VICDI0TrAe+FtkwCOit+n DQxWFBz4sEWbGuTSEgExi/JPSyIHlR1Xy92bNx8QVVpPIyqJen15OBlATPSFsOcIFglx cS32xOVNqVP82Ln6ZeL/gi963RPdzHf2X47LjZEsbfmRs/zzAXVPj+JLCwH2HXyEv6uM chtHg2fCCwu4bJlacDUE8M8kAFIjrHMoRON4rccT/1hoTbkOzLFWn++ObmOW92ZdtQrP rNww==
X-Received: by 10.194.185.230 with SMTP id ff6mr5419411wjc.120.1410202391488;  Mon, 08 Sep 2014 11:53:11 -0700 (PDT)
Received: from [10.0.0.9] (bzq-79-177-135-86.red.bezeqint.net. [79.177.135.86]) by mx.google.com with ESMTPSA id ua8sm12088829wjc.7.2014.09.08.11.53.07 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Sep 2014 11:53:11 -0700 (PDT)
Message-ID: <540DFB07.6000806@gmail.com>
Date: Mon, 08 Sep 2014 21:52:55 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Paul_Koning@Dell.com, paul@nohats.ca
References: <540CA9B2.3090807@gmail.com> <BE175F90-68B6-4731-B32E-BA9EF3F3BAD8@dell.com> <alpine.LFD.2.10.1409081412050.23553@bofh.nohats.ca> <7C9AB479-042F-4039-9F02-4483F9C8385C@dell.com>
In-Reply-To: <7C9AB479-042F-4039-9F02-4483F9C8385C@dell.com>
Content-Type: text/plain; charset=windows-1255; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Wsdqsak3XxeV5gqQgx3d6V7VlIs
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Sep 2014 18:53:14 -0000

Paul and Paul (and yet another Paul),

Just a process comment: this is a call for adoption, a "first call" not 
a last call. There may still be many issues with the document, which we 
will fix as a group *if* the document is adopted. So is the document 
dealing with an important problem, and is it good enough as a starting 
point of a solution?

Thanks,
	Yaron


From nobody Mon Sep  8 12:51:16 2014
Return-Path: <Paul_Koning@dell.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7ED51A0340 for <ipsec@ietfa.amsl.com>; Mon,  8 Sep 2014 12:51:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.953
X-Spam-Level: 
X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMtd6r3RSvHg for <ipsec@ietfa.amsl.com>; Mon,  8 Sep 2014 12:51:14 -0700 (PDT)
Received: from ausxipps310.us.dell.com (AUSXIPPS310.us.dell.com [143.166.148.211]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0A11A0326 for <ipsec@ietf.org>; Mon,  8 Sep 2014 12:51:14 -0700 (PDT)
DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:Return-Path; b=JSvvKHXkpGcTMa5oZh3s3ML1Tm/bxxrdiXQhuHTm1M1BU1RAT+w/UXpQ 3Frp6OigZgrPKcADkCztEOePRJs4fC/prLbij5UAf2XWrhxdrtLVn7D9A iE0w03YAOcD7H7jbAkRZjlL67JmFFFfT6Tc2hhGxcPQfLSl8Q6EtGRHL3 k=;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1410205874; x=1441741874; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Cf745U+4u0EHXgpbyqISvT7troDJ/tJtSzirSiCRw8M=; b=v2/b3CO3/49uyjHEWCp3E4jmWush7Jwy5kP92O3tyQ6JnanfstC+oyD4 HvWm3DxjI0yPkQ9USmqYW4ht8weIN7I7+xcxiVkpzhfou97uA0P291Rhi Lp3WJg8y7Ml6sCqTacYC22GjE0+lrit9NmlVYQL+cIawTmrEVXnEhccAo 4=;
X-LoopCount0: from 10.175.216.251
X-IronPort-AV: E=Sophos;i="5.04,488,1406610000"; d="scan'208";a="80158074"
From: <Paul_Koning@Dell.com>
To: <yaronf.ietf@gmail.com>
Thread-Topic: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol
Thread-Index: AQHPy3S+pO6kHNlTNUC0lCro6ItLEpv330YAgAAFiwCAAARKgIAAEDSA
Date: Mon, 8 Sep 2014 19:51:11 +0000
Message-ID: <619F8199-A01A-4964-9717-831B72698AAE@dell.com>
References: <540CA9B2.3090807@gmail.com> <BE175F90-68B6-4731-B32E-BA9EF3F3BAD8@dell.com> <alpine.LFD.2.10.1409081412050.23553@bofh.nohats.ca> <7C9AB479-042F-4039-9F02-4483F9C8385C@dell.com> <540DFB07.6000806@gmail.com>
In-Reply-To: <540DFB07.6000806@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.152.216.26]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <C286D0E0E9A01643BBBE069757BC7F50@dell.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Kxz7Z8yFRU4j6bqb1Gyab1DKKBA
Cc: ipsec@ietf.org, paul@nohats.ca
Subject: Re: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Sep 2014 19:51:15 -0000

On Sep 8, 2014, at 2:52 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

> Paul and Paul (and yet another Paul),
>=20
> Just a process comment: this is a call for adoption, a "first call" not a=
 last call. There may still be many issues with the document, which we will=
 fix as a group *if* the document is adopted. So is the document dealing wi=
th an important problem, and is it good enough as a starting point of a sol=
ution?
>=20
> Thanks,
> 	Yaron

Thanks for pointing that out.  Thinking of this as =93first call=94 helps a=
 lot.

Ok, then my answer is =93yes=94 =97 reason being =93this is an important pr=
oblem to fix and the direction makes sense=94.

	paul


From nobody Mon Sep  8 17:23:33 2014
Return-Path: <hugokraw@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737601A02C2 for <ipsec@ietfa.amsl.com>; Mon,  8 Sep 2014 17:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTp6qTPNQw0n for <ipsec@ietfa.amsl.com>; Mon,  8 Sep 2014 17:23:28 -0700 (PDT)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27061A0266 for <ipsec@ietf.org>; Mon,  8 Sep 2014 17:23:21 -0700 (PDT)
Received: by mail-lb0-f180.google.com with SMTP id b12so1086983lbj.11 for <ipsec@ietf.org>; Mon, 08 Sep 2014 17:23:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=0EvlatmQw++6GsweoSU+3WmCaCLr9/h9ae38Ggtrr8Q=; b=I9gmPCBd6T93r+Bi4kQTE8H78cD2LV8S8t7vuPM9/WhayvODi3EKoRpOlhKT8oByAi VtVL6yeFtg7F153J7FJPxjxrbkmXyBxaBlwh5NAKCRwSvvsmNiMXDKA/i0QjltyTcHTO 6ceXY2/lKcaD7MzAjwxGEIgG1/Hm/vuMvxT1mpH9FShQDle4PAY4XTgyXA9KhK/wbluY wVSOstwWTkwQmctiSQxJfr/Rw1+XAcRLyfibkIesS/iQy03lYoCS9bJRcbzSgGCtYIDb Pq/9h25IfeV5PCy02qr3/+zNfzBbTmGDPUCgnY/b8ocQcBnBpKC/TVelB2augNpTwSc7 tyQg==
X-Received: by 10.152.42.231 with SMTP id r7mr32466317lal.23.1410222200137; Mon, 08 Sep 2014 17:23:20 -0700 (PDT)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by 10.25.16.135 with HTTP; Mon, 8 Sep 2014 17:22:50 -0700 (PDT)
In-Reply-To: <BE175F90-68B6-4731-B32E-BA9EF3F3BAD8@dell.com>
References: <540CA9B2.3090807@gmail.com> <BE175F90-68B6-4731-B32E-BA9EF3F3BAD8@dell.com>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Mon, 8 Sep 2014 20:22:50 -0400
X-Google-Sender-Auth: CL9JzxCZq3A34Glk82cKDXL3Hpg
Message-ID: <CADi0yUM3ESC9A1WaJJZ5QKrAeUd-wiNLFRdpRUYp5vGXir-A6Q@mail.gmail.com>
To: Paul_Koning@dell.com
Content-Type: multipart/alternative; boundary=001a11c34bc64b2b46050296f109
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/IJr0K2YHLFaLZgX7t-saq0Y_fYg
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Sep 2014 00:23:30 -0000

--001a11c34bc64b2b46050296f109
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The subject line (and the comment on Bellovin attack) caught my eye. I
don't follow the discussions in this list so I don't know how much the need
and dangers of unauthenticated methods were discussed here. I want to point
out that (and probably many did before me) that un-authentication is a very
tricky option especially in a protocol that was created with mutual
authentication as a core requirement and assumption. I can see potential
benefits and uses but I can also see it abused and misused (the internet
draft doesn't do too good a job warning about it but even if it did, people
will misuse it).

But requirements aside, I cannot vow for the security of IKE's key exchange
in a one-way authentication mode. No one (that I know, definitely not me)
designed this protocol to support one-way authentication. So the question
of whether it is secure in this setting has not been investigated.
Moreover, I see that the draft uses shared-key fields for the anonymous
side of the communication and, I imagine, the other can use signature-based
authentication. What security properties do you get from that mix-and-match
authentication methods?

One likely misuse of this technique is that people will use unauthenticated
(or one-way) IKE and will run some other authentication on top of it (say,
password based or whatever). Well, protocols do not necessarily compose
securely. TLS had many failures like that (BEAST, re-negotiation, triple
handshake, ...) and IPsec saw examples of that in the combinations of
unauthenticated ESP and AH. IKE's cryptographic design has endured the test
of time but these variations (or improvisations) endanger it.

Finally, since Bellovin's attack was mentioned, I want to make sure that no
one is thinking of not using the MAC authentication at the IP packet level,
right?

Hugo






On Mon, Sep 8, 2014 at 10:54 AM, <Paul_Koning@dell.com> wrote:

>
> On Sep 7, 2014, at 2:53 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
>
> > Dear working group,
> >
> > This is a call for adopting draft-smyslov-ipsecme-ikev2-null-auth as a
> WG document. Please respond to this mail with a Yes or No and a short
> rationale, at latest by Friday Sep. 12.
>
> Maybe.
>
> I understand and support the rationale for this draft.
>
> The Security Considerations seems to be inadequate.  Whenever possible,
> real authentication should be used.  So the Security Considerations shoul=
d
> explicitly and strongly emphasize that, and recommend that products that
> incorporate Null authentication should strive to avoid its use whenever
> possible, and steer users away from its use when they can.
>
> A related question: does the use of Null authentication open up the
> Bellovin attack?  It seems that it would.  If so, my answer changes to =
=E2=80=9CNO=E2=80=9D.
>
>         paul
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>

--001a11c34bc64b2b46050296f109
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:verdana,=
sans-serif;font-size:small">The subject line (and the comment on Bellovin a=
ttack) caught my eye. I don&#39;t follow the discussions in this list so I =
don&#39;t know how much the need and dangers of unauthenticated methods wer=
e discussed here. I want to point out that (and probably many did before me=
) that un-authentication is a very tricky option especially in a protocol t=
hat was created with mutual authentication as a core requirement and assump=
tion. I can see potential benefits and uses but I can also see it abused an=
d misused (the internet draft doesn&#39;t do too good a job warning about i=
t but even if it did, people will misuse it).<br><br>But requirements aside=
, I cannot vow for the security of IKE&#39;s key exchange in a one-way auth=
entication mode. No one (that I know, definitely not me) designed this prot=
ocol to support one-way authentication. So the question of whether it is se=
cure in this setting has not been investigated. Moreover, I see that the dr=
aft uses shared-key fields for the anonymous side of the communication and,=
 I imagine, the other can use signature-based authentication. What security=
 properties do you get from that mix-and-match authentication methods? <br>=
<br></div><div class=3D"gmail_default" style=3D"font-family:verdana,sans-se=
rif;font-size:small">One likely misuse of this technique is that people wil=
l use unauthenticated (or one-way) IKE and will run some other authenticati=
on on top of it (say, password based or whatever). Well, protocols do not n=
ecessarily compose securely. TLS had many failures like that (BEAST, re-neg=
otiation, triple handshake, ...) and IPsec saw examples of that in the comb=
inations of unauthenticated ESP and AH. IKE&#39;s cryptographic design has =
endured the test of time but these variations (or improvisations) endanger =
it.<br><br></div><div class=3D"gmail_default" style=3D"font-family:verdana,=
sans-serif;font-size:small">Finally, since Bellovin&#39;s attack was mentio=
ned, I want to make sure that no one is thinking of not using the MAC authe=
ntication at the IP packet level, right? <br><br></div><div class=3D"gmail_=
default" style=3D"font-family:verdana,sans-serif;font-size:small">Hugo<br><=
br></div><div class=3D"gmail_default" style=3D"font-family:verdana,sans-ser=
if;font-size:small"><br><br></div><div class=3D"gmail_default" style=3D"fon=
t-family:verdana,sans-serif;font-size:small"><br><br></div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Mon, Sep 8, 2014 at 10:54 AM, =
 <span dir=3D"ltr">&lt;<a href=3D"mailto:Paul_Koning@dell.com" target=3D"_b=
lank">Paul_Koning@dell.com</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><span class=3D""><br>
On Sep 7, 2014, at 2:53 PM, Yaron Sheffer &lt;<a href=3D"mailto:yaronf.ietf=
@gmail.com">yaronf.ietf@gmail.com</a>&gt; wrote:<br>
<br>
&gt; Dear working group,<br>
&gt;<br>
&gt; This is a call for adopting draft-smyslov-ipsecme-ikev2-null-auth as a=
 WG document. Please respond to this mail with a Yes or No and a short rati=
onale, at latest by Friday Sep. 12.<br>
<br>
</span>Maybe.<br>
<br>
I understand and support the rationale for this draft.<br>
<br>
The Security Considerations seems to be inadequate.=C2=A0 Whenever possible=
, real authentication should be used.=C2=A0 So the Security Considerations =
should explicitly and strongly emphasize that, and recommend that products =
that incorporate Null authentication should strive to avoid its use wheneve=
r possible, and steer users away from its use when they can.<br>
<br>
A related question: does the use of Null authentication open up the Bellovi=
n attack?=C2=A0 It seems that it would.=C2=A0 If so, my answer changes to =
=E2=80=9CNO=E2=80=9D.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 paul<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
_______________________________________________<br>
IPsec mailing list<br>
<a href=3D"mailto:IPsec@ietf.org">IPsec@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/ipsec" target=3D"_blank">h=
ttps://www.ietf.org/mailman/listinfo/ipsec</a><br>
</div></div></blockquote></div><br></div></div>

--001a11c34bc64b2b46050296f109--


From nobody Tue Sep  9 00:11:07 2014
Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813411A0B0E for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 00:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.561
X-Spam-Level: 
X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlWyOGZ81_c8 for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 00:11:05 -0700 (PDT)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96AAD1A0B13 for <ipsec@ietf.org>; Tue,  9 Sep 2014 00:11:04 -0700 (PDT)
Received: by mail-la0-f45.google.com with SMTP id pn19so18927436lab.32 for <ipsec@ietf.org>; Tue, 09 Sep 2014 00:11:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=tQbFijjMBa2W4aL4s2R1abEuK12cxq46ECgGRAxI9Gk=; b=nibHjV8XNgIXjVJ9BqHWFHbAA4T1jhMw5n1H/i9CzzTRkC1Udc48R1Zy/OhKyQZsRs swpwuqoR1tu04PGpoP19Djx/OG6lXvuj36zRyTnCyaTjruXULDn79r6WiuSyi2Yp46Se QNbYSpx/laA52IulJBgb0qVDoQojjkbFIs6/5eqTx0mHygIXFzoxgJCJkmSy5rYGhYSo h7VUY3/bimtdZT+eE05IDgQtzrtloM1epJMmEaEJ6SQW6vvs43yWCr4VohyxrWQ1dXwS vwmGX0N6UwKCybd0S1IxYKwz9Ksel0wSdGBVxZlJGHNxK022AmVSglcrg7QxW/839xnz S2rw==
X-Received: by 10.152.36.37 with SMTP id n5mr889406laj.93.1410246662870; Tue, 09 Sep 2014 00:11:02 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id i3sm3991639laa.8.2014.09.09.00.11.00 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Sep 2014 00:11:01 -0700 (PDT)
Message-ID: <0666BB9DE8304DC1891658BFA9FF7EF7@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Graham Bartlett \(grbartle\)" <grbartle@cisco.com>, "Yaron Sheffer" <yaronf.ietf@gmail.com>, "ipsec" <ipsec@ietf.org>
References: <540CA9B2.3090807@gmail.com> <DCC36F8DE78A4E5280A9977B4CAC144A@buildpc> <D033575C.2C348%grbartle@cisco.com>
Date: Tue, 9 Sep 2014 11:11:21 +0400
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="windows-1251"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/iIg_0Lq6xuPpX649CG0x6h4t4ew
Subject: Re: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2Protocol
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Sep 2014 07:11:06 -0000

Hi Graham,

> I have one Q.
> 
> If endpoint receives a request to create an unauthenticated IKE SA
> from the IP address, which is configured on the endpoint to be
> authenticated, the request SHOULD be rejected.
> 
> Why is this not MUST be rejected ? Otherwise an attacker could trick the
> responder into revealing their identity (maybe some words around this
> also?).

I was thinking of two possible cases here.
First, even if the initiator was able to certify its identity, 
it might want to keep anonymity for this particular
connection (for example to prevent tracking its
activity). And the other case - the responder's configuration
could be out of date and the IP address it was
configured to be authenticated could already
belong to some other, anonymous host.

Anyway, while SHOULD is pretty strong requirement,
it is not ultimate here: I'm not absolutely sure
that the above cases completely justify it over MUST.
We can discuss it.

And you are right - some (I dare to say "many")
words still need to be added into the Security Considerations
section.

Regards,
Valery.


> Thanks
> 
> Graham
> 
> 
> On 08/09/2014 07:27, "Valery Smyslov" <svanru@gmail.com> wrote:
> 
>>Yes.
>>
>>Obviously, as the author of the document I can see its value,
>>which is describet in the document itself.
>>And I think it's better to standardize it with
>>more people involved, than as individual submission.
>>
>>Regards,
>>Valery.
>>
>>----- Original Message -----
>>From: "Yaron Sheffer" <yaronf.ietf@gmail.com>
>>To: "ipsec" <ipsec@ietf.org>
>>Sent: Sunday, September 07, 2014 10:53 PM
>>Subject: [IPsec] Call for adoption: The NULL Authentication Method in
>>IKEv2Protocol
>>
>>
>>> Dear working group,
>>>
>>> This is a call for adopting draft-smyslov-ipsecme-ikev2-null-auth as a
>>>WG 
>>> document. Please respond to this mail with a Yes or No and a short
>>> rationale, at latest by Friday Sep. 12.
>>>
>>> Thanks,
>>> Yaron
>>>
>>> _______________________________________________
>>> IPsec mailing list
>>> IPsec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>>_______________________________________________
>>IPsec mailing list
>>IPsec@ietf.org
>>https://www.ietf.org/mailman/listinfo/ipsec
>


From nobody Tue Sep  9 00:42:07 2014
Return-Path: <mglt.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E141A0B78 for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 00:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6VnzlMP-w1Y for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 00:42:02 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5F6B1A0B75 for <ipsec@ietf.org>; Tue,  9 Sep 2014 00:42:01 -0700 (PDT)
Received: by mail-wi0-f173.google.com with SMTP id em10so14987wid.0 for <ipsec@ietf.org>; Tue, 09 Sep 2014 00:42:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Auwgj8x8Hi5l2bEpwQVOFoVbict+fCxUraRwWLdqciE=; b=aCZF33D1KeuxnFpezS6jJBcGajmx4siyJGhzgj52tv92mA6ti4Gsupc56C8BNF2r97 UtvS03Il0T5aSZzjnAneUiPwkPgi87RBnfMdS4pR7//App8RvdBQX8vrME0RQBIgahjk oNe5gjj2ZhTEEJg49o0pg0e/gmh5X9q6iCkFJHLN3pxfjE/Pb5k4+XsZ2s9uqtIUeyrB bDB+Ibbh04LWfP02QlOK11nJktySX0YwHJ+KhzSPNP/TCyNQq+wyw4kZvOuzDwH5nSGN g0HWfY3X5/PY0aIk0uZRG0q/m0D0GOr3di8yAHZxeL9w1BHSFLrDCVg6vFMYSfFMiCES 4cdA==
MIME-Version: 1.0
X-Received: by 10.194.63.205 with SMTP id i13mr40847190wjs.74.1410248520134; Tue, 09 Sep 2014 00:42:00 -0700 (PDT)
Received: by 10.194.137.67 with HTTP; Tue, 9 Sep 2014 00:42:00 -0700 (PDT)
In-Reply-To: <540CA9B2.3090807@gmail.com>
References: <540CA9B2.3090807@gmail.com>
Date: Tue, 9 Sep 2014 09:42:00 +0200
Message-ID: <CADZyTkno_g0DaHgQ6cnx5HFcQS-XWVz3c_bonZgCHgz=GFnr0g@mail.gmail.com>
From: Daniel Migault <mglt.ietf@gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=047d7ba97a801674dc05029d1202
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/NV7pWBTwikLxrq93xqjvU8fcv74
Cc: ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Sep 2014 07:42:04 -0000

--047d7ba97a801674dc05029d1202
Content-Type: text/plain; charset=UTF-8

Hi,

I am in favor of adopting this draft. In my case I see it as a way to ease
IPsec deployment in IoT with opportunistic encryption.

BR,
Daniel

On Sun, Sep 7, 2014 at 8:53 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

> Dear working group,
>
> This is a call for adopting draft-smyslov-ipsecme-ikev2-null-auth as a WG
> document. Please respond to this mail with a Yes or No and a short
> rationale, at latest by Friday Sep. 12.
>
> Thanks,
>         Yaron
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>



-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

--047d7ba97a801674dc05029d1202
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Hi, <br><br></div>I am in favor of adopting=
 this draft. In my case I see it as a way to ease IPsec deployment in IoT w=
ith opportunistic encryption. <br><br></div>BR, <br></div>Daniel<br></div><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Sep 7, 201=
4 at 8:53 PM, Yaron Sheffer <span dir=3D"ltr">&lt;<a href=3D"mailto:yaronf.=
ietf@gmail.com" target=3D"_blank">yaronf.ietf@gmail.com</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">Dear working group,<br>
<br>
This is a call for adopting draft-smyslov-ipsecme-ikev2-<u></u>null-auth as=
 a WG document. Please respond to this mail with a Yes or No and a short ra=
tionale, at latest by Friday Sep. 12.<br>
<br>
Thanks,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron<br>
<br>
______________________________<u></u>_________________<br>
IPsec mailing list<br>
<a href=3D"mailto:IPsec@ietf.org" target=3D"_blank">IPsec@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/ipsec" target=3D"_blank">h=
ttps://www.ietf.org/mailman/<u></u>listinfo/ipsec</a><br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Daniel Migault<br>Orang=
e Labs -- Security<br>+33 6 70 72 69 58
</div>

--047d7ba97a801674dc05029d1202--


From nobody Tue Sep  9 02:41:44 2014
Return-Path: <leposo@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF911A06B6 for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 02:41:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qjnoz-1_DZvl for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 02:41:39 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928B01A89BA for <ipsec@ietf.org>; Tue,  9 Sep 2014 02:41:26 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id m15so2740834wgh.7 for <ipsec@ietf.org>; Tue, 09 Sep 2014 02:41:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=88pt4P/rd33D8KERwFiYSidcUzdBj/IxvRflhERkoEM=; b=pVF+gxA6weYF4qCgQjbOknmFhWcyASOa8Z6ezXsHVfF0ctkg480RBBffTWfoKZVdpR SIQnufhKZOUrAgJQiPBY9fkmhQMfghNMCj4j2HeJgeNDNzoj5x1jDb1Oxo8Im30DI9Eu 4rwtcXvfgFrPxwHXnXM7LrSNAbU0ZnxGIFoXfAatWGFQRMRI3I/BD5F5fCcAzm9+SWBs lA+IrrI6mrnzmSMubs37XB2m68JbxvrV/PtWSEEtXymJDIiPz202gdcwFNNQPZTjzqLq wp/LGz8g2SiPAB/O57JP3z8rMDLMa9E1kM/H616WYMbmitww5mACL/S3a2V2BN6ubey6 eY/g==
X-Received: by 10.180.35.134 with SMTP id h6mr29283866wij.0.1410255685253; Tue, 09 Sep 2014 02:41:25 -0700 (PDT)
Received: from [192.168.0.17] ([41.212.114.217]) by mx.google.com with ESMTPSA id lm18sm14886092wic.22.2014.09.09.02.41.21 for <ipsec@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Sep 2014 02:41:24 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Les Leposo <leposo@gmail.com>
In-Reply-To: <mailman.73.1410202825.8991.ipsec@ietf.org>
Date: Tue, 9 Sep 2014 12:40:31 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <94FA376D-8F43-4327-B4E6-8E4BF06C7D60@gmail.com>
References: <mailman.73.1410202825.8991.ipsec@ietf.org>
To: ipsec@ietf.org
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/4v6OAlPtFNQzkj8gSMCHZ8hO4_s
Subject: Re: [IPsec] IPsec Digest, Vol 125, Issue 9
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Sep 2014 09:41:41 -0000

imho, this would be useful for bring-up work i.e. for both developers =
and deployers.

However, as folks already pointed out, there are significant security =
tradeoffs (and mitigations) that SHOULD/MUST to be explicated (i.e.more =
verbiage).
Points to consider:
1) allowing unauthenticated IKE-SAs (and in turn CHILD-SAs) to be =
established, would open up opportunities for ikev2 "exhaustion attacks" =
that previously weren't there (on the server side), no?

2) this feature could also tempt network admins to fallback to 'null =
authentication' as a work-around/short-cut in cases where they are =
unable to properly configure a deployment.

It would help if better use cases are highlighted:
A) the anonymity use case is subjective because, one could simply use a =
psk/cert that identifies an "access group" as opposed to an "individual" =
psk/cert, no?

B) the "low power" sensor use case is also subjective because, if the =
sensor data is truly confidential, would you want to make sure the =
sensor wont be redirected to a rogue/fake server?

$0.02

On Sep 8, 2014, at 10:00 PM, ipsec-request@ietf.org wrote:

> Send IPsec mailing list submissions to
> 	ipsec@ietf.org
>=20
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/ipsec
> or, via email, send a message with subject or body 'help' to
> 	ipsec-request@ietf.org
>=20
> You can reach the person managing the list at
> 	ipsec-owner@ietf.org
>=20
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of IPsec digest..."
>=20
>=20
> Today's Topics:
>=20
>   1. Re: Call for adoption: The NULL Authentication Method in
>      IKEv2 Protocol (Yaron Sheffer)
>=20
>=20
> ----------------------------------------------------------------------
>=20
> Message: 1
> Date: Mon, 08 Sep 2014 21:52:55 +0300
> From: Yaron Sheffer <yaronf.ietf@gmail.com>
> To: Paul_Koning@Dell.com, paul@nohats.ca
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] Call for adoption: The NULL Authentication Method
> 	in IKEv2 Protocol
> Message-ID: <540DFB07.6000806@gmail.com>
> Content-Type: text/plain; charset=3Dwindows-1255; format=3Dflowed
>=20
> Paul and Paul (and yet another Paul),
>=20
> Just a process comment: this is a call for adoption, a "first call" =
not=20
> a last call. There may still be many issues with the document, which =
we=20
> will fix as a group *if* the document is adopted. So is the document=20=

> dealing with an important problem, and is it good enough as a starting=20=

> point of a solution?
>=20
> Thanks,
> 	Yaron
>=20
>=20
>=20
> ------------------------------
>=20
> Subject: Digest Footer
>=20
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>=20
>=20
> ------------------------------
>=20
> End of IPsec Digest, Vol 125, Issue 9
> *************************************


From nobody Tue Sep  9 04:08:07 2014
Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912131A6FCA for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 04:08:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.561
X-Spam-Level: 
X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOkS2W1Zmz4q for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 04:08:03 -0700 (PDT)
Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2F11A6FD3 for <ipsec@ietf.org>; Tue,  9 Sep 2014 04:08:02 -0700 (PDT)
Received: by mail-la0-f54.google.com with SMTP id b17so19385454lan.13 for <ipsec@ietf.org>; Tue, 09 Sep 2014 04:08:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=glMGF1s3y8aMW5SQLR1S4/TdrDHtZe3a+mEObV5j4FM=; b=B5syUZi3Z/svXS8HVO4lTaF9BhyfFZ2sL3OR2U8xlfWGRIw0zt3MFnraqifCL8+XUY PfnnOM3BME2ac43wXaK4sEPE5ogSLnt1loLVWMtEQ0hy3yCmL52Wayf9as/r6PCPA46R VyVHLHoOE5YOkFiTDrPtoD1f8UAENYUef1TQWXZN1ZvbBnbD6/jhoMaYBAFo0KkUFgoY 38soctAzjWkDGtLMTlvEKnqOnEwN922MiEoHC3yTPzgAhYn1C3j+262smyqA6T8jEkB0 XmcByp1EwLpz7B6r5Jzq4w3nJ0INB52I7Loe3m097hqT35n4nn6THiSlHhJIKkN6mnLU MCVA==
X-Received: by 10.152.27.38 with SMTP id q6mr35453188lag.60.1410260880255; Tue, 09 Sep 2014 04:08:00 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id xh2sm4454396lbb.7.2014.09.09.04.07.58 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Sep 2014 04:07:59 -0700 (PDT)
Message-ID: <CFA40702822144168203534F70552EA9@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Les Leposo" <leposo@gmail.com>, <ipsec@ietf.org>
References: <mailman.73.1410202825.8991.ipsec@ietf.org> <94FA376D-8F43-4327-B4E6-8E4BF06C7D60@gmail.com>
Date: Tue, 9 Sep 2014 15:08:21 +0400
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/1G-VyU2gnW8eYxzxmNQxwQJk0TM
Subject: Re: [IPsec] IPsec Digest, Vol 125, Issue 9
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Sep 2014 11:08:05 -0000

Hi Les,

> imho, this would be useful for bring-up work i.e. for both developers and 
> deployers.
>
> However, as folks already pointed out, there are significant security 
> tradeoffs (and mitigations) that SHOULD/MUST to be explicated (i.e.more 
> verbiage).
> Points to consider:
> 1) allowing unauthenticated IKE-SAs (and in turn CHILD-SAs) to be 
> established, would open up opportunities for ikev2 "exhaustion attacks" 
> that previously weren't there (on the server side), no?

Not really more than now. Currently an attacker could
perform IKE_SA_INIT, and then send bogus signature
in IKE_AUTH. The server will need to do DH and to
perform signature verification before rejecting the connection.
With NULL Authentication the server will not do
signature verification, that saves some CPU resources,
and will only sign itself.

And the server could always limit the number of unauthenticated connections

> 2) this feature could also tempt network admins to fallback to 'null 
> authentication' as a work-around/short-cut in cases where they are unable 
> to properly configure a deployment.

The Security Considerations must strongly discourage to do it.

> It would help if better use cases are highlighted:
> A) the anonymity use case is subjective because, one could simply use a 
> psk/cert that identifies an "access group" as opposed to an "individual" 
> psk/cert, no?

Yes, it is possible. But there are some disadvantages comparing to special 
mode.
For example, with "group cert" one will need to perform an expensive
public cryptography operations, that are unnecessary in this case.

> B) the "low power" sensor use case is also subjective because, if the 
> sensor data is truly confidential, would you want to make sure the sensor 
> wont be redirected to a rogue/fake server?

It is presumed in this example, that the measurment itself is not secret
(for example, the temperature of the air). If the sensor is redirected,
the attacker won't get any new information. It propably should
be spelled out more explicitely in the draft.

Regards,
Valery.

> $0.02
>
> On Sep 8, 2014, at 10:00 PM, ipsec-request@ietf.org wrote:
>
>> Send IPsec mailing list submissions to
>> ipsec@ietf.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://www.ietf.org/mailman/listinfo/ipsec
>> or, via email, send a message with subject or body 'help' to
>> ipsec-request@ietf.org
>>
>> You can reach the person managing the list at
>> ipsec-owner@ietf.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of IPsec digest..."
>>
>>
>> Today's Topics:
>>
>>   1. Re: Call for adoption: The NULL Authentication Method in
>>      IKEv2 Protocol (Yaron Sheffer)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Mon, 08 Sep 2014 21:52:55 +0300
>> From: Yaron Sheffer <yaronf.ietf@gmail.com>
>> To: Paul_Koning@Dell.com, paul@nohats.ca
>> Cc: ipsec@ietf.org
>> Subject: Re: [IPsec] Call for adoption: The NULL Authentication Method
>> in IKEv2 Protocol
>> Message-ID: <540DFB07.6000806@gmail.com>
>> Content-Type: text/plain; charset=windows-1255; format=flowed
>>
>> Paul and Paul (and yet another Paul),
>>
>> Just a process comment: this is a call for adoption, a "first call" not
>> a last call. There may still be many issues with the document, which we
>> will fix as a group *if* the document is adopted. So is the document
>> dealing with an important problem, and is it good enough as a starting
>> point of a solution?
>>
>> Thanks,
>> Yaron
>>
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>>
>> ------------------------------
>>
>> End of IPsec Digest, Vol 125, Issue 9
>> *************************************
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec 


From nobody Tue Sep  9 04:09:14 2014
Return-Path: <ivo.sedlacek@ericsson.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFE01A6FC9 for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 04:09:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acxpIolDyD3U for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 04:09:11 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61A611A6FC3 for <ipsec@ietf.org>; Tue,  9 Sep 2014 04:09:10 -0700 (PDT)
X-AuditID: c1b4fb3a-f79da6d0000008c7-10-540edfd44b39
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 3E.BD.02247.4DFDE045; Tue,  9 Sep 2014 13:09:08 +0200 (CEST)
Received: from ESESSMB301.ericsson.se ([169.254.1.77]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0174.001; Tue, 9 Sep 2014 13:09:07 +0200
From: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
To: "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: Review of draft-gundavelli-ipsecme-3gpp-ims-options-02
Thread-Index: Ac/MFsZIKMQYWriGR/e+ppRj0kUPVQ==
Date: Tue, 9 Sep 2014 11:09:07 +0000
Message-ID: <39B5E4D390E9BD4890E2B310790061011272E731@ESESSMB301.ericsson.se>
Accept-Language: en-US, cs-CZ
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.147]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvje6V+3whBm8fyVgsmreAyWL/lhds FvvXNTBZdB2czmZx8M82NgdWj1n3z7J5TPm9kdVj56y77B5LlvxkCmCJ4rJJSc3JLEst0rdL 4MqYv/Qfc8F2g4rHpy6zNTDuVeti5OCQEDCRWDPBtYuRE8gUk7hwbz1bFyMXh5DAUUaJGz0r mCCcRYwSEzfvYQapYhPQk5i45QgriC0ioCpxatl0VpAiZoFNjBINvWfBEsIC9hITds5lgyhy kZjceQXK1pNYvXAD2CAWARWJKZ+mMYHYvAK+EvP/3GQHsRkFZCWu/ullBLGZBcQlbj2ZzwRx noDEkj3nmSFsUYmXj/+xQnygJDFtaxpEuY7Egt2f2CBsbYllC18zQ4wXlDg58wnLBEaRWUim zkLSMgtJyywkLQsYWVYxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBEbQwS2/rXYwHnzueIhR gINRiYdXIZ4vRIg1say4MvcQozQHi5I478Jz84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1 ME5yer72umOtOpvBzZZtcV6TJ8y3mFqWuOigv0XA/qxdh3Qf9gipNlyV3GH7NXvt7XnOTF8y 6/5eXRXAZHLp2oQ2jaX9plFVkcFP+L+eV+Oy41w5zfxLcq/Z/CTXM+/2nb96hW1p0CzPvx17 +1f6e2e5m/3k2qrFcuyBhZuLYVzD9Jv3w9U8PiixFGckGmoxFxUnAgCVhb0vgQIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/mnFouMWps33ObOVyhNXJ8AV3B4w
Cc: "noblea@cisco.com" <noblea@cisco.com>, Jouni Korhonen <jouni.nospam@gmail.com>, "baboescu@broadcom.com" <baboescu@broadcom.com>, "sgundave@cisco.com" <sgundave@cisco.com>
Subject: [IPsec] Review of draft-gundavelli-ipsecme-3gpp-ims-options-02
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Sep 2014 11:09:14 -0000

Hello,

I reviewed http://tools.ietf.org/id/draft-gundavelli-ipsecme-3gpp-ims-optio=
ns-02.txt and found the following issues:

ISSUE 1: the draft states:
------
These attributes can be
   used for carrying the IPv4 and IPv6 address of the Proxy-Call Control
   and Service function (P-CSCF).
------
In 3GPP, P-CSCF abbreviation stands for "Proxy-Call Session Control Functio=
n".

PROPOSAL 1: state:
------
These attributes can be
   used for carrying the IPv4 address and IPv6 address of the Proxy-Call Se=
ssion Control function (P-CSCF).
------

ISSUE 2: the draft states:
------
When an IPSec gateway delivers these
   attributes to an IPsec client, it can obtain the IPv4 and/or IPv6
   address of the P-CSCF server located in the home network.
------
The P-CSCF does not necessarily need to be located in the home network. In =
roaming situations, the P-CSCF can also be in visited network. =20
Example: User has a contract with an European operator. The user with its u=
ser equipment (UE) is in Japan and uses network of a Japanese operator. In =
such use case, the ePDG entity, the PGW entity and P-CSCF can all be in vis=
ited network (i.e. Japanese operator network).

PROPOSAL 2: state:
------
When an IPSec gateway delivers these
   attributes to an IPsec client, the IPsec client can obtain the IPv4 and/=
or IPv6
   address of the P-CSCF server located in the 3GPP network.
------

ISSUE 3: the draft states:
------
   The Third Generation Partnership Project (3GPP) S2b reference point
   [TS23402], specified by the 3GPP system architecture defines a
   mechanism for allowing a mobile node (MN) attached in an untrusted
   non-3GPP IP Access Network to securely connect to the 3GPP home
   network and access IP services.
------
When roaming, the UE can access IP services in the 3GPP home network or 3GP=
P visited network. ePDG can be in visited or home network - see  http://www=
.3gpp.org/ftp/Specs/archive/23_series/23.402/23402-c50.zip section 4.5.4. I=
f so, P-GW and P-CSCF can also be in the visited network.

PROPOSAL 3: state:
------
   The Third Generation Partnership Project (3GPP) S2b reference point
   [TS23402], specified by the 3GPP system architecture defines a
   mechanism for allowing a mobile node (MN) attached in an untrusted
   non-3GPP IP Access Network to securely connect to a 3GPP=20
   network and access IP services.
------

ISSUE 4: the draft states:
------
   A mobile node in this scenario may potentially need to access the IP
   Multimedia Subsystem (IMS) services in the home network.
------
P-CSCF can also be in visited network.

PROPOSAL 4: state:
------
   A mobile node in this scenario may potentially need to access the IP
   Multimedia Subsystem (IMS) services in the 3GPP network.
------

ISSUE 5: the draft states:
------
   Proxy-Call Session Control Function (P-CSCF)

      The P-CSCF is the entry point to the 3GPP IMS (IP Multimedia
      Subsystem) domain and serves as the outbound proxy server for the
      mobile node.  The mobile node attaches to the P-CSCF prior to
      performing IMS registrations and initiating SIP sessions.
------
Problems:
1) 3GPP IMS is not a domain.
2) The mobile node does NOT attach to P-CSCF prior to performing the IMS re=
gistration. Instead, the registration with IMS is the request for "attachme=
nt" to IMS.

PROPOSAL 5: state:
------
   Proxy-Call Session Control Function (P-CSCF)

      The P-CSCF is the entry point to the 3GPP IMS (IP Multimedia
      Subsystem)  and serves as the SIP outbound proxy for the
      mobile node.  The mobile node performs SIP registration to 3GPP IMS a=
nd initiates SIP sessions via a P-CSCF.
------

ISSUE 6: the draft states:
------
Multiple P-CSCF
   servers MAY be requested by including a single instance of an empty
   P-CSCF_IP4_ADDRESS attribute with zero-length IPv4 Address field.
   The responder MAY respond with zero or more P-CSCF_IP4_ADDRESS
   attributes, and there is no implied order in the response.
------
IMO, the 1st sentence above is misleading as it suggests that the mobile no=
de has a choise to request one P-CSCF IPv4 address or to request multiple P=
-CSCF IPv4 addresses. However, in my reading of the rest of the draft, the =
mobile node has just one choise - request P-CSCF IPv4 addresses and receive=
 zero, one or several P-CSCF IPv4 addresses.

PROPOSAL 6: state:
------
If an instance of an empty
   P-CSCF_IP4_ADDRESS attribute with zero-length IPv4 Address field is incl=
uded by mobile node, the responder MAY respond with zero, one or more P-CSC=
F_IP4_ADDRESS
   attributes. If several P-CSCF_IP4_ADDRESS attributes are provided in one=
 IKEv2 message, there is no implied order among the P-CSCF_IP4_ADDRESS attr=
ibutes.
------

ISSUE 7: the draft states:
------
Multiple P-CSCF
   servers MAY be requested by including a single instance of an empty
   P-CSCF_IP6_ADDRESS attribute with zero-length IPv6 Address field.
   The responder MAY respond with zero or more P-CSCF_IP6_ADDRESS
   attributes, and there is no implied order in the response.
------
IMO, the 1st sentence above is misleading as it suggests that the mobile no=
de has a choise to request one P-CSCF IPv6 address or to request multiple P=
-CSCF IPv6 addresses. However, in my reading of the rest of the draft, the =
mobile node has just one choise - request P-CSCF IPv6 addresses and receive=
 zero, one or several P-CSCF IPv6 addresses.

PROPOSAL 7: state:
------
If an instance of an empty
   P-CSCF_IP6_ADDRESS attribute with zero-length IPv6 Address field is incl=
uded by mobile node, the responder MAY respond with zero, one or more P-CSC=
F_IP6_ADDRESS
   attributes. If several P-CSCF_IP6_ADDRESS attributes are provided in one=
 IKEv2 message, there is no implied order among the P-CSCF_IP6_ADDRESS attr=
ibutes.
------

Kind regards

Ivo Sedlacek
Ericsson
Mobile +420 608 234 709
ivo.sedlacek@ericsson.com
www.ericsson.com

This Communication is Confidential. We only send and receive email on the b=
asis of the terms set out at www.ericsson.com/email_disclaimer


From nobody Tue Sep  9 04:58:01 2014
Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930781A0052 for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 04:57:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ov4dtZULW70T for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 04:57:56 -0700 (PDT)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F521A0068 for <ipsec@ietf.org>; Tue,  9 Sep 2014 04:57:53 -0700 (PDT)
Received: by mail-lb0-f182.google.com with SMTP id v6so2717770lbi.27 for <ipsec@ietf.org>; Tue, 09 Sep 2014 04:57:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:from:to:cc:references:subject:date:mime-version :content-type; bh=NLTSre2mKJyI+Xnod0p+m4qilxz6VWZgYnhByS41740=; b=K1KtWy4p0FoEoqmzZ1uB2KgiV1bmN6FsKrvzjQec2uO2Egh8J/a9VLd/DxnXPRIW1P RaHhh+Lsx/ngrCkatMj168RM/hb97qfcM0kb3OfI+hDxF2q26z7SikuZ/dF5jE7RZzNn Y3wQZreVJtA2iwW2A5A/jJPzpBjYTXqQMEMt9k9EAQjwdtGz8ZA7d55v3FNSshGGMcW4 PW5CEBvD7aX25TNCnqGz70yIfm9yReYDpXtm0Wny/kM8aSuG5CPS8t0NOgc55KRNdl2f WV89+S20S+ELpIwfMvcRmhaUUi1hzrB04EA/bOWEajKRek5nrI1AfFvnBWvSOUYLYdeS w2aQ==
X-Received: by 10.112.202.106 with SMTP id kh10mr33622423lbc.66.1410263871888;  Tue, 09 Sep 2014 04:57:51 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id s8sm4218833las.29.2014.09.09.04.57.49 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Sep 2014 04:57:50 -0700 (PDT)
Message-ID: <6E9345DD1E9A43158A0DD61F96C09741@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Hugo Krawczyk" <hugo@ee.technion.ac.il>, <Paul_Koning@dell.com>
References: <540CA9B2.3090807@gmail.com> <BE175F90-68B6-4731-B32E-BA9EF3F3BAD8@dell.com> <CADi0yUM3ESC9A1WaJJZ5QKrAeUd-wiNLFRdpRUYp5vGXir-A6Q@mail.gmail.com>
Date: Tue, 9 Sep 2014 15:58:11 +0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_020A_01CFCC46.DB1B4C10"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/9JlyyMzSC07oV6PYWMiGEwj48mQ
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Sep 2014 11:57:59 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_020A_01CFCC46.DB1B4C10
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Hugo,
  The subject line (and the comment on Bellovin attack) caught my eye. I =
don't follow the discussions in this list so I don't know how much the =
need and dangers of unauthenticated methods were discussed here. I want =
to point out that (and probably many did before me) that =
un-authentication is a very tricky option especially in a protocol that =
was created with mutual authentication as a core requirement and =
assumption. I can see potential benefits and uses but I can also see it =
abused and misused (the internet draft doesn't do too good a job warning =
about it but even if it did, people will misuse it).
I agree that the draft's Security Consideration section in its current =
form is incomplete.
And I hope that if the draft is adopted then it will draw an attention =
of many people,
who will help to improve the Security Considerations to list all the =
caveats,
to make all possible warning and to give advice how to safely use this =
mode.
  But requirements aside, I cannot vow for the security of IKE's key =
exchange in a one-way authentication mode. No one (that I know, =
definitely not me) designed this protocol to support one-way =
authentication. So the question of whether it is secure in this setting =
has not been investigated. Moreover, I see that the draft uses =
shared-key fields for theanonymous side of the communication and, I =
imagine, the other can use signature-based authentication. What security =
properties do you get from that mix-and-match authentication methods?=20
IKEv2 currently allows the peers to use different authentication =
methods.=20
So, if one of the peers uses preshared key, while the other uses=20
digital signature, then it is considered legal and secure from
protocol's design point of view. If the peer, using preshared key in =
this scenario,
uses key, known to everyone, then we will get one-way authentication
with the current IKEv2. The next step, that the draft does - get rid of=20
well-known preshared key and compute the content of the AUTH Payload
the same way it is computed currently in IKEv2 when it is used
with non key generating EAP methods - using SK_pi (or SK_Pr) as the key
I believe the draft doesn't change the way cryptography is used in =
IKEv2.
  One likely misuse of this technique is that people will use =
unauthenticated (or one-way) IKE and will run some other authentication =
on top of it (say, password based or whatever). Well, protocols do not =
necessarily compose securely. TLS had many failures like that (BEAST, =
re-negotiation, triple handshake, ...) and IPsec saw examples of that in =
the combinations of unauthenticated ESP and AH. IKE's cryptographic =
design has endured the test of time but these variations (or =
improvisations) endanger it.
Well, sometimes mutual authentication is impossible or undesirable.
Sometimes privacy is more important and people are ready to
sacrifice some level of security to keep their privacy.
And sometimes the choice is - either use plaintext
or unauthenticated encryption. The latter at least
prevents passive eavesdropping...
  Finally, since Bellovin's attack was mentioned, I want to make sure =
that no one is thinking of not using the MAC authentication at the IP =
packet level, right?=20
Absolutely.
  Hugo
Regards,
Valery Smyslov.
  On Mon, Sep 8, 2014 at 10:54 AM, <Paul_Koning@dell.com> wrote:


    On Sep 7, 2014, at 2:53 PM, Yaron Sheffer <yaronf.ietf@gmail.com> =
wrote:

    > Dear working group,
    >
    > This is a call for adopting draft-smyslov-ipsecme-ikev2-null-auth =
as a WG document. Please respond to this mail with a Yes or No and a =
short rationale, at latest by Friday Sep. 12.

    Maybe.

    I understand and support the rationale for this draft.

    The Security Considerations seems to be inadequate.  Whenever =
possible, real authentication should be used.  So the Security =
Considerations should explicitly and strongly emphasize that, and =
recommend that products that incorporate Null authentication should =
strive to avoid its use whenever possible, and steer users away from its =
use when they can.

    A related question: does the use of Null authentication open up the =
Bellovin attack?  It seems that it would.  If so, my answer changes to =
=E2=80=9CNO=E2=80=9D.

            paul


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





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


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

------=_NextPart_000_020A_01CFCC46.DB1B4C10
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dutf-8" http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.23588">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Hi Hugo,</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; =
PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
  <DIV>The subject line (and the comment on Bellovin attack) caught my =
eye. I=20
  don't follow the discussions in this list so I don't know how much the =
need=20
  and dangers of unauthenticated methods were discussed here. I want to =
point=20
  out that (and probably many did before me) that un-authentication is a =
very=20
  tricky option especially in a protocol that was created with mutual=20
  authentication as a core requirement and assumption. I can see =
potential=20
  benefits and uses but I can also see it abused and misused (the =
internet draft=20
  doesn't do too good a job warning about it but even if it did, people =
will=20
  misuse it).</DIV></BLOCKQUOTE>
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 face=3DArial>I agree that the =
draft's Security=20
Consideration section in its current form is incomplete.</FONT></DIV>
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 face=3DArial>And I hope that if the =
draft is=20
adopted then it will draw an attention of many people,</FONT></DIV>
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 face=3DArial>who will help to =
improve the=20
Security Considerations&nbsp;to list all the caveats,</FONT></DIV>
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 face=3DArial>to make all possible =
warning and to=20
give advice how to safely use this mode.</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; =
PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small" =
dir=3Dltr=20
  class=3Dgmail_default>But requirements aside, I cannot vow for the =
security of=20
  IKE's key exchange in a one-way authentication mode. No one (that I =
know,=20
  definitely not me) designed this protocol to support one-way =
authentication.=20
  So the question of whether it is secure in this setting has not been=20
  investigated. Moreover, I see that the draft uses shared-key fields =
for=20
  theanonymous side of the communication and, I imagine, the other can =
use=20
  signature-based authentication. What security properties do you get =
from that=20
  mix-and-match authentication methods? </DIV></BLOCKQUOTE>
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 face=3DArial>
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 face=3DArial><FONT size=3D2 =
face=3DArial>IKEv2=20
currently allows the peers to use different authentication =
methods.</FONT>=20
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 face=3DArial>So, if one of the =
peers uses=20
preshared key, while the other uses </FONT></DIV>
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 face=3DArial>digital signature, =
then it is=20
considered legal and secure from</FONT></DIV>
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 face=3DArial>protocol's design =
point of view. If=20
the peer, using preshared key in this scenario,</FONT></DIV>
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 face=3DArial>uses key, known to=20
everyone,&nbsp;then we will get one-way authentication</FONT></DIV>
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 face=3DArial>with the current =
IKEv2. The next=20
step, that the draft does - get rid of </FONT></DIV>
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 face=3DArial>well-known preshared =
key and compute=20
the content of the AUTH Payload</FONT></DIV>
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 face=3DArial>the same way it is =
computed=20
currently in IKEv2 when it is used</FONT></DIV>
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 face=3DArial>with non key =
generating EAP methods=20
- using SK_pi (or SK_Pr) as the key</FONT></DIV>
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 face=3DArial>I believe the draft =
doesn't=20
</FONT><FONT size=3D2 face=3DArial>change the way cryptography is used =
in=20
IKEv2.</FONT></DIV></FONT></DIV></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; =
PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small" =
dir=3Dltr=20
  class=3Dgmail_default>One likely misuse of this technique is that =
people will=20
  use unauthenticated (or one-way) IKE and will run some other =
authentication on=20
  top of it (say, password based or whatever). Well, protocols do not=20
  necessarily compose securely. TLS had many failures like that (BEAST,=20
  re-negotiation, triple handshake, ...) and IPsec saw examples of that =
in the=20
  combinations of unauthenticated ESP and AH. IKE's cryptographic design =
has=20
  endured the test of time but these variations (or improvisations) =
endanger=20
  it.</DIV></BLOCKQUOTE>
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 face=3DArial></FONT><FONT size=3D2 =
face=3DArial>Well,=20
sometimes mutual authentication is impossible or =
undesirable.</FONT></DIV>
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 face=3DArial>Sometimes privacy is =
more important=20
and people are ready to</FONT></DIV>
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 face=3DArial>sacrifice some level =
of security to=20
keep their privacy.</FONT></DIV>
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 face=3DArial>And sometimes the =
choice is - either=20
use plaintext</FONT></DIV>
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 face=3DArial>or unauthenticated =
encryption. The=20
latter at least</FONT></DIV>
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 face=3DArial>prevents passive=20
eavesdropping...</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; =
PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small" =
dir=3Dltr=20
  class=3Dgmail_default>Finally, since Bellovin's attack was mentioned, =
I want to=20
  make sure that no one is thinking of not using the MAC authentication =
at the=20
  IP packet level, right? </DIV></BLOCKQUOTE>
<DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small"=20
class=3Dgmail_default><FONT size=3D2 =
face=3DArial>Absolutely.</FONT></DIV><FONT=20
size=3D2></FONT>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; =
PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
  <DIV>Hugo</DIV></BLOCKQUOTE>
<DIV><FONT size=3D2>Regards,</FONT></DIV>
<DIV><FONT size=3D2>Valery Smyslov.</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; =
PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT-FAMILY: verdana,sans-serif; FONT-SIZE: small" =
dir=3Dltr=20
  class=3Dgmail_default>On Mon, Sep 8, 2014 at 10:54 AM, <SPAN =
dir=3Dltr>&lt;<A=20
  href=3D"mailto:Paul_Koning@dell.com"=20
  target=3D_blank>Paul_Koning@dell.com</A>&gt;</SPAN> wrote:<BR></DIV>
  <DIV dir=3Dltr class=3Dgmail_extra>
  <DIV class=3Dgmail_quote>
  <BLOCKQUOTE=20
  style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; =
PADDING-LEFT: 1ex"=20
  class=3Dgmail_quote><SPAN><FONT size=3D2></FONT><FONT =
size=3D2></FONT><FONT=20
    size=3D2></FONT><BR>On Sep 7, 2014, at 2:53 PM, Yaron Sheffer &lt;<A =

    href=3D"mailto:yaronf.ietf@gmail.com">yaronf.ietf@gmail.com</A>&gt;=20
    wrote:<BR><BR>&gt; Dear working group,<BR>&gt;<BR>&gt; This is a =
call for=20
    adopting draft-smyslov-ipsecme-ikev2-null-auth as a WG document. =
Please=20
    respond to this mail with a Yes or No and a short rationale, at =
latest by=20
    Friday Sep. 12.<BR><BR></SPAN>Maybe.<BR><BR>I understand and support =
the=20
    rationale for this draft.<BR><BR>The Security Considerations seems =
to be=20
    inadequate.&nbsp; Whenever possible, real authentication should be=20
    used.&nbsp; So the Security Considerations should explicitly and =
strongly=20
    emphasize that, and recommend that products that incorporate Null=20
    authentication should strive to avoid its use whenever possible, and =
steer=20
    users away from its use when they can.<BR><BR>A related question: =
does the=20
    use of Null authentication open up the Bellovin attack?&nbsp; It =
seems that=20
    it would.&nbsp; If so, my answer changes to =
=E2=80=9CNO=E2=80=9D.<BR><BR>&nbsp; &nbsp;=20
    &nbsp; &nbsp; paul<BR>
    <DIV class=3DHOEnZb>
    <DIV =
class=3Dh5><BR>_______________________________________________<BR>IPsec=20
    mailing list<BR><A =
href=3D"mailto:IPsec@ietf.org">IPsec@ietf.org</A><BR><A=20
    href=3D"https://www.ietf.org/mailman/listinfo/ipsec"=20
    =
target=3D_blank>https://www.ietf.org/mailman/listinfo/ipsec</A><BR></DIV>=
</DIV></BLOCKQUOTE></DIV><BR></DIV>
  <P>
  <HR>

  <P></P>_______________________________________________<BR>IPsec =
mailing=20
  =
list<BR>IPsec@ietf.org<BR>https://www.ietf.org/mailman/listinfo/ipsec<BR>=
</BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_020A_01CFCC46.DB1B4C10--


From nobody Tue Sep  9 05:40:37 2014
Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7761A00BF for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 05:40:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.652
X-Spam-Level: 
X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd5pOenuynmT for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 05:40:29 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 168D31A00B9 for <ipsec@ietf.org>; Tue,  9 Sep 2014 05:40:29 -0700 (PDT)
Received: from [193.110.157.231] (unknown [76.10.157.65]) by bofh.nohats.ca (Postfix) with ESMTPSA id 93E9F80111; Tue,  9 Sep 2014 08:40:27 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1410266427; bh=/pY4+2hxHKvTPuX3SS/JngITwo5fPtII3YSqDxbRMHg=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=ZomvZX3BokifmFQpd1VUmLt3J5mz2Ikc/xq6cAxBsBJmr0/vjvyfXLIslF9mNxUoz pklntAe2T25Q1+U5uW+wziL+AHRcKIgHI3MHsMHV5hcBjPxFCktUY6NtAlhq3tXr31 zX4FIk2KzDQUciOMEiJZ3x5/WeeRVkJjYP3gC8hc=
References: <mailman.73.1410202825.8991.ipsec@ietf.org> <94FA376D-8F43-4327-B4E6-8E4BF06C7D60@gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <94FA376D-8F43-4327-B4E6-8E4BF06C7D60@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <44D2B499-6A1B-407B-BCCF-83BF1CBC9813@nohats.ca>
X-Mailer: iPhone Mail (11D257)
From: Paul <paul@nohats.ca>
Date: Tue, 9 Sep 2014 08:40:26 -0400
To: Les Leposo <leposo@gmail.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/4gBjjXgvh7JOsTh4UpWsq9Nckg0
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec] IPsec Digest, Vol 125, Issue 9
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Sep 2014 12:40:32 -0000

> On Sep 9, 2014, at 5:40, Les Leposo <leposo@gmail.com> wrote:
>=20
> imho, this would be useful for bring-up work i.e. for both developers and d=
eployers.
>=20
> However, as folks already pointed out, there are significant security trad=
eoffs (and mitigations) that SHOULD/MUST to be explicated (i.e.more verbiage=
).
> Points to consider:
> 1) allowing unauthenticated IKE-SAs (and in turn CHILD-SAs) to be establis=
hed, would open up opportunities for ikev2 "exhaustion attacks" that previou=
sly weren't there (on the server side), no?

Yes it could use up some more CPU and ram. But it's a trade of the admin mak=
es.

> 2) this feature could also tempt network admins to fallback to 'null authe=
ntication' as a work-around/short-cut in cases where they are unable to prop=
erly configure a deployment.

Or they just configure a psk "test". No difference.

> It would help if better use cases are highlighted:
> A) the anonymity use case is subjective because, one could simply use a ps=
k/cert that identifies an "access group" as opposed to an "individual" psk/c=
ert, no?

Not sure what you mean with subjective in this context. But one sided anonym=
ity isn't the same as both ends authenticating with psk "test". The server c=
an still use a strong rsa key that the client authenticates. It is just that=
 the server doesn't authenticate the client because it accepts crypto from a=
nyone.

> B) the "low power" sensor use case is also subjective because, if the sens=
or data is truly confidential, would you want to make sure the sensor wont b=
e redirected to a rogue/fake server?

Same here. The iot device can have a firmware rsa key of the server used to a=
uthenticate the server, while the client is not authenticated.

Paul

>=20


From nobody Tue Sep  9 06:19:37 2014
Return-Path: <leposo@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225581A03FE for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 06:19:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4b-17MefdSF for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 06:19:33 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D962E1A0323 for <ipsec@ietf.org>; Tue,  9 Sep 2014 06:19:29 -0700 (PDT)
Received: by mail-wi0-f173.google.com with SMTP id em10so501028wid.12 for <ipsec@ietf.org>; Tue, 09 Sep 2014 06:19:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:message-id :references:to; bh=UvjjUSVjdJMP2UIbr2cdrUNJFXlmn+IeSDjNgoMPD+k=; b=yoXnmG3HjhSjdcHqy6xSErtb0mrt9l6UzA7bqL8es9SCsw3eCGPFyy+o34fnYOsYAn PMzjvbvTHjJtpR/fPmvarun582SgaMTDsbxKa1wwisBSHmS6g3C1bmNOWCuA4YrYKPO3 7TEDkT5m/L4JCJ2faY6qwBX56sqR2r1XQzHXtMRhxHTeZKxHTnTIl6h/cV5areAiN12X w1Z5O+3HOelMbpmIMtW3hAX0km3vDMzksHGvZtGKQ9oqDEhroEQixy4b691WttLvM8lN ejdSiy5CE0jSwaGyJRLo8Y+fXDPF0cLWyZJm6spYT0aGrFkBx75y93MXNfYooxGpSKi2 jUAw==
X-Received: by 10.180.75.9 with SMTP id y9mr220995wiv.79.1410268768539; Tue, 09 Sep 2014 06:19:28 -0700 (PDT)
Received: from [192.168.0.17] ([41.212.114.217]) by mx.google.com with ESMTPSA id h3sm14897077wjz.24.2014.09.09.06.19.26 for <ipsec@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Sep 2014 06:19:27 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_566A1A31-F12D-4CCE-86FC-294BDDABDF10"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Les Leposo <leposo@gmail.com>
X-Priority: 3
In-Reply-To: <CFA40702822144168203534F70552EA9@buildpc>
Date: Tue, 9 Sep 2014 16:19:22 +0300
Message-Id: <31CE6896-F796-4C6D-BE00-51EBE281294E@gmail.com>
References: <mailman.73.1410202825.8991.ipsec@ietf.org> <94FA376D-8F43-4327-B4E6-8E4BF06C7D60@gmail.com> <CFA40702822144168203534F70552EA9@buildpc>
To: "ipsec@ietf.org WG" <ipsec@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Rn_o4Z6AUjOThPxBPfvxkiq5XFw
Subject: Re: [IPsec] IPsec Digest, Vol 125, Issue 9
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Sep 2014 13:19:36 -0000

--Apple-Mail=_566A1A31-F12D-4CCE-86FC-294BDDABDF10
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Hi Valery,

On Sep 9, 2014, at 2:08 PM, Valery Smyslov <svanru@gmail.com> wrote:

> Hi Les,
>=20
>> imho, this would be useful for bring-up work i.e. for both developers =
and deployers.
>>=20
>> However, as folks already pointed out, there are significant security =
tradeoffs (and mitigations) that SHOULD/MUST to be explicated (i.e.more =
verbiage).
>> Points to consider:
>> 1) allowing unauthenticated IKE-SAs (and in turn CHILD-SAs) to be =
established, would open up opportunities for ikev2 "exhaustion attacks" =
that previously weren't there (on the server side), no?
>=20
> Not really more than now. Currently an attacker could
> perform IKE_SA_INIT, and then send bogus signature
> in IKE_AUTH. The server will need to do DH and to
> perform signature verification before rejecting the connection.
> With NULL Authentication the server will not do
> signature verification, that saves some CPU resources,
> and will only sign itself.
Sure, CPU and RAM are not as expensive as "fast-path" or SA "tables" =
typical found in servers with hardware acceleration - prior to this =
proposal, these expensive resources were (typically) reserved only after =
authentication (and child SA nego succeeded).
However, with this proposal, the server will be allocating these =
resources anyhow because it can't judge between a good vs. bad client.

>=20
> And the server could always limit the number of unauthenticated =
connections
>=20
absolutely, it would help the server implementors, if this proposal =
required such safe guards- others would be rate-limiting and perhaps =
shorter Child-SA lifetimes.

>> 2) this feature could also tempt network admins to fallback to 'null =
authentication' as a work-around/short-cut in cases where they are =
unable to properly configure a deployment.
>=20
> The Security Considerations must strongly discourage to do it.
>=20
Concur.

>> It would help if better use cases are highlighted:
>> A) the anonymity use case is subjective because, one could simply use =
a psk/cert that identifies an "access group" as opposed to an =
"individual" psk/cert, no?
>=20
> Yes, it is possible. But there are some disadvantages comparing to =
special mode.
> For example, with "group cert" one will need to perform an expensive
> public cryptography operations, that are unnecessary in this case.
>=20
>> B) the "low power" sensor use case is also subjective because, if the =
sensor data is truly confidential, would you want to make sure the =
sensor wont be redirected to a rogue/fake server?
>=20
> It is presumed in this example, that the measurment itself is not =
secret
> (for example, the temperature of the air). If the sensor is =
redirected,
> the attacker won't get any new information. It propably should
> be spelled out more explicitely in the draft.
Concur, the sensor data would have to be inconsequential.

Because even when the measurement is not secret, a rogue "sensor" could =
easily pollute the central data which could be bad especially if the =
data is consequently used to control e.g. the cooling plant.

>=20
> Regards,
> Valery.
>=20
>> $0.02
>>=20
>> On Sep 8, 2014, at 10:00 PM, ipsec-request@ietf.org wrote:
>>=20
>>> Send IPsec mailing list submissions to
>>> ipsec@ietf.org
>>>=20
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> https://www.ietf.org/mailman/listinfo/ipsec
>>> or, via email, send a message with subject or body 'help' to
>>> ipsec-request@ietf.org
>>>=20
>>> You can reach the person managing the list at
>>> ipsec-owner@ietf.org
>>>=20
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of IPsec digest..."
>>>=20
>>>=20
>>> Today's Topics:
>>>=20
>>>  1. Re: Call for adoption: The NULL Authentication Method in
>>>     IKEv2 Protocol (Yaron Sheffer)
>>>=20
>>>=20
>>> =
----------------------------------------------------------------------
>>>=20
>>> Message: 1
>>> Date: Mon, 08 Sep 2014 21:52:55 +0300
>>> From: Yaron Sheffer <yaronf.ietf@gmail.com>
>>> To: Paul_Koning@Dell.com, paul@nohats.ca
>>> Cc: ipsec@ietf.org
>>> Subject: Re: [IPsec] Call for adoption: The NULL Authentication =
Method
>>> in IKEv2 Protocol
>>> Message-ID: <540DFB07.6000806@gmail.com>
>>> Content-Type: text/plain; charset=3Dwindows-1255; format=3Dflowed
>>>=20
>>> Paul and Paul (and yet another Paul),
>>>=20
>>> Just a process comment: this is a call for adoption, a "first call" =
not
>>> a last call. There may still be many issues with the document, which =
we
>>> will fix as a group *if* the document is adopted. So is the document
>>> dealing with an important problem, and is it good enough as a =
starting
>>> point of a solution?
>>>=20
>>> Thanks,
>>> Yaron
>>>=20
>>>=20
>>>=20
>>> ------------------------------
>>>=20
>>> Subject: Digest Footer
>>>=20
>>> _______________________________________________
>>> IPsec mailing list
>>> IPsec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>=20
>>>=20
>>> ------------------------------
>>>=20
>>> End of IPsec Digest, Vol 125, Issue 9
>>> *************************************
>>=20
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec


--Apple-Mail=_566A1A31-F12D-4CCE-86FC-294BDDABDF10
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Diso-8859-1"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi =
Valery,<div><br><div><div>On Sep 9, 2014, at 2:08 PM, Valery Smyslov =
&lt;<a href=3D"mailto:svanru@gmail.com">svanru@gmail.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div style=3D"font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;">Hi Les,<br><br><blockquote =
type=3D"cite">imho, this would be useful for bring-up work i.e. for both =
developers and deployers.<br><br>However, as folks already pointed out, =
there are significant security tradeoffs (and mitigations) that =
SHOULD/MUST to be explicated (i.e.more verbiage).<br>Points to =
consider:<br>1) allowing unauthenticated IKE-SAs (and in turn CHILD-SAs) =
to be established, would open up opportunities for ikev2 "exhaustion =
attacks" that previously weren't there (on the server side), =
no?<br></blockquote><br>Not really more than now. Currently an attacker =
could<br>perform IKE_SA_INIT, and then send bogus signature<br>in =
IKE_AUTH. The server will need to do DH and to<br>perform signature =
verification before rejecting the connection.<br>With NULL =
Authentication the server will not do<br>signature verification, that =
saves some CPU resources,<br>and will only sign =
itself.<br></div></blockquote><div>Sure, CPU and RAM are not as =
expensive as "fast-path" or SA "tables" typical found in servers with =
hardware acceleration - prior to this proposal, these expensive =
resources were (typically) reserved only after authentication (and child =
SA nego succeeded).</div><div>However, with this proposal, the server =
will be allocating these resources anyhow because it can't judge between =
a good vs. bad client.</div><div><br></div><blockquote type=3D"cite"><div =
style=3D"font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px;"><br>And the server could always limit =
the number of unauthenticated =
connections<br><br></div></blockquote>absolutely, it would help the =
server implementors, if this proposal required such safe guards- others =
would be rate-limiting and perhaps shorter Child-SA =
lifetimes.</div><div><br><blockquote type=3D"cite"><div =
style=3D"font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px;"><blockquote type=3D"cite">2) this =
feature could also tempt network admins to fallback to 'null =
authentication' as a work-around/short-cut in cases where they are =
unable to properly configure a deployment.<br></blockquote><br>The =
Security Considerations must strongly discourage to do =
it.<br><br></div></blockquote>Concur.</div><div><br><blockquote =
type=3D"cite"><div style=3D"font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;"><blockquote type=3D"cite">It would =
help if better use cases are highlighted:<br>A) the anonymity use case =
is subjective because, one could simply use a psk/cert that identifies =
an "access group" as opposed to an "individual" psk/cert, =
no?<br></blockquote><br>Yes, it is possible. But there are some =
disadvantages comparing to special mode.<br>For example, with "group =
cert" one will need to perform an expensive<br>public cryptography =
operations, that are unnecessary in this case.<br><br><blockquote =
type=3D"cite">B) the "low power" sensor use case is also subjective =
because, if the sensor data is truly confidential, would you want to =
make sure the sensor wont be redirected to a rogue/fake =
server?<br></blockquote><br>It is presumed in this example, that the =
measurment itself is not secret<br>(for example, the temperature of the =
air). If the sensor is redirected,<br>the attacker won't get any new =
information. It propably should<br>be spelled out more explicitely in =
the draft.<br></div></blockquote>Concur, the sensor data would have to =
be inconsequential.</div><div><br></div><div>Because even when the =
measurement is not secret, a rogue "sensor" could easily pollute the =
central data which could be bad especially if the data is consequently =
used to control e.g. the cooling =
plant.</div><div><br></div><div><blockquote type=3D"cite"><div =
style=3D"font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: =
0px;"><br>Regards,<br>Valery.<br><br><blockquote =
type=3D"cite">$0.02<br><br>On Sep 8, 2014, at 10:00 PM, <a =
href=3D"mailto:ipsec-request@ietf.org">ipsec-request@ietf.org</a> =
wrote:<br><br><blockquote type=3D"cite">Send IPsec mailing list =
submissions to<br><a =
href=3D"mailto:ipsec@ietf.org">ipsec@ietf.org</a><br><br>To subscribe or =
unsubscribe via the World Wide Web, =
visit<br>https://www.ietf.org/mailman/listinfo/ipsec<br>or, via email, =
send a message with subject or body 'help' =
to<br>ipsec-request@ietf.org<br><br>You can reach the person managing =
the list at<br>ipsec-owner@ietf.org<br><br>When replying, please edit =
your Subject line so it is more specific<br>than "Re: Contents of IPsec =
digest..."<br><br><br>Today's Topics:<br><br>&nbsp;1. Re: Call for =
adoption: The NULL Authentication Method =
in<br>&nbsp;&nbsp;&nbsp;&nbsp;IKEv2 Protocol (Yaron =
Sheffer)<br><br><br>------------------------------------------------------=
----------------<br><br>Message: 1<br>Date: Mon, 08 Sep 2014 21:52:55 =
+0300<br>From: Yaron Sheffer &lt;yaronf.ietf@gmail.com&gt;<br>To: =
Paul_Koning@Dell.com, paul@nohats.ca<br>Cc: ipsec@ietf.org<br>Subject: =
Re: [IPsec] Call for adoption: The NULL Authentication Method<br>in =
IKEv2 Protocol<br>Message-ID: =
&lt;540DFB07.6000806@gmail.com&gt;<br>Content-Type: text/plain; =
charset=3Dwindows-1255; format=3Dflowed<br><br>Paul and Paul (and yet =
another Paul),<br><br>Just a process comment: this is a call for =
adoption, a "first call" not<br>a last call. There may still be many =
issues with the document, which we<br>will fix as a group *if* the =
document is adopted. So is the document<br>dealing with an important =
problem, and is it good enough as a starting<br>point of a =
solution?<br><br>Thanks,<br>Yaron<br><br><br><br>-------------------------=
-----<br><br>Subject: Digest =
Footer<br><br>_______________________________________________<br>IPsec =
mailing =
list<br>IPsec@ietf.org<br>https://www.ietf.org/mailman/listinfo/ipsec<br><=
br><br>------------------------------<br><br>End of IPsec Digest, Vol =
125, Issue =
9<br>*************************************<br></blockquote><br>___________=
____________________________________<br>IPsec mailing list<br><a =
href=3D"mailto:IPsec@ietf.org">IPsec@ietf.org</a><br><a =
href=3D"https://www.ietf.org/mailman/listinfo/ipsec">https://www.ietf.org/=
mailman/listinfo/ipsec</a></blockquote></div></blockquote></div><br></div>=
</body></html>=

--Apple-Mail=_566A1A31-F12D-4CCE-86FC-294BDDABDF10--


From nobody Tue Sep  9 06:26:05 2014
Return-Path: <leposo@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8338A1A0323 for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 06:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9kZaJNcqcmh for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 06:26:02 -0700 (PDT)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83151A02F0 for <ipsec@ietf.org>; Tue,  9 Sep 2014 06:26:01 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id x13so4651537wgg.21 for <ipsec@ietf.org>; Tue, 09 Sep 2014 06:26:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=lui5ZH9+vTXCtyMR7D+oXJhQtAqaLy0VoHtDI/DLUpE=; b=Qtzi75tRiPNjfwojuJv0Iu378p1O9eNhhv1vqnSvlUr0C/Wr0I8GzNGl4b9lubvpuV G+Z1UnN1ebOwO58aVhKDx276fUQdrC7KGP38TJt47ei/un5PxOt9gyRMHRm3uWhbRfRw Oyz4xVQasS2fE+hAOVM6YW4aXWgYgcBq7/2H5u6d0CQSqSSWaIv279GhaNVRKPNLJD02 VKByUt4uHvoakcnXwW31lo2UtpOQloOTrRRdVkBO6tC4Ad/OtHl2JOIKIS0vhGwGMDvS zayJVhTvxHdIEjr+4MTWUqaDSOXwMhquQNW1+npdROsv6pyRZ7Si/fztXosA2cyASQgT a7uQ==
X-Received: by 10.194.57.67 with SMTP id g3mr42193609wjq.60.1410269160454; Tue, 09 Sep 2014 06:26:00 -0700 (PDT)
Received: from [192.168.0.17] ([41.212.114.217]) by mx.google.com with ESMTPSA id q3sm15602724wia.14.2014.09.09.06.25.58 for <ipsec@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Sep 2014 06:25:59 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Les Leposo <leposo@gmail.com>
In-Reply-To: <44D2B499-6A1B-407B-BCCF-83BF1CBC9813@nohats.ca>
Date: Tue, 9 Sep 2014 16:25:55 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <2AEF9649-E01D-4DE0-94B2-2FC21BBC7042@gmail.com>
References: <mailman.73.1410202825.8991.ipsec@ietf.org> <94FA376D-8F43-4327-B4E6-8E4BF06C7D60@gmail.com> <44D2B499-6A1B-407B-BCCF-83BF1CBC9813@nohats.ca>
To: "ipsec@ietf.org" <ipsec@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/HHVeD6tCSCwZQtOm-TopRaUJ-2Q
Subject: Re: [IPsec] IPsec Digest, Vol 125, Issue 9
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Sep 2014 13:26:03 -0000

Hi Paul,

On Sep 9, 2014, at 3:40 PM, Paul <paul@nohats.ca> wrote:

>=20
>=20
>> On Sep 9, 2014, at 5:40, Les Leposo <leposo@gmail.com> wrote:
>>=20
>> imho, this would be useful for bring-up work i.e. for both developers =
and deployers.
>>=20
>> However, as folks already pointed out, there are significant security =
tradeoffs (and mitigations) that SHOULD/MUST to be explicated (i.e.more =
verbiage).
>> Points to consider:
>> 1) allowing unauthenticated IKE-SAs (and in turn CHILD-SAs) to be =
established, would open up opportunities for ikev2 "exhaustion attacks" =
that previously weren't there (on the server side), no?
>=20
> Yes it could use up some more CPU and ram. But it's a trade of the =
admin makes.
Concur, but the admin would need to be given sufficient warning, through =
this document.

>=20
>> 2) this feature could also tempt network admins to fallback to 'null =
authentication' as a work-around/short-cut in cases where they are =
unable to properly configure a deployment.
>=20
> Or they just configure a psk "test". No difference.

>=20
>> It would help if better use cases are highlighted:
>> A) the anonymity use case is subjective because, one could simply use =
a psk/cert that identifies an "access group" as opposed to an =
"individual" psk/cert, no?
>=20
> Not sure what you mean with subjective in this context. But one sided =
anonymity isn't the same as both ends authenticating with psk "test". =
The server can still use a strong rsa key that the client authenticates. =
It is just that the server doesn't authenticate the client because it =
accepts crypto from anyone.
But accepting crypto from anyone is like a big "Kick Me" sign on the =
server's spec sheet.

>=20
>> B) the "low power" sensor use case is also subjective because, if the =
sensor data is truly confidential, would you want to make sure the =
sensor wont be redirected to a rogue/fake server?
>=20
> Same here. The iot device can have a firmware rsa key of the server =
used to authenticate the server, while the client is not authenticated.
>=20
Great.

> Paul
>=20
>>=20


From nobody Tue Sep  9 06:27:18 2014
Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA061A02EA for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 06:27:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.652
X-Spam-Level: 
X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRzjlUeZyD2G for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 06:27:15 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F84F1A02ED for <ipsec@ietf.org>; Tue,  9 Sep 2014 06:27:15 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3CA5C80111; Tue,  9 Sep 2014 09:27:14 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1410269234; bh=j0Z1BsgrD3pNmxmhYhMgYTJl3IB42CB6hNjMPbqdL1U=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=s+k055ycC8yptnu1roYZ6cIppmdnHhwhuB6GAoZlGupqnF8+0luR730mVVFHAy5tU yfFw6beuU+tgeAf3gWRXVafALoGpt1ABEc+E0v6HGh5n9TtoxhR/eWVTkZhX9xGst6 Uvuvkbw2xq9TntN56tRWa9kBXMo6DvG8bf6wDuEw=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s89DRDFI011442; Tue, 9 Sep 2014 09:27:13 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Tue, 9 Sep 2014 09:27:13 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Les Leposo <leposo@gmail.com>
In-Reply-To: <31CE6896-F796-4C6D-BE00-51EBE281294E@gmail.com>
Message-ID: <alpine.LFD.2.10.1409090921480.26597@bofh.nohats.ca>
References: <mailman.73.1410202825.8991.ipsec@ietf.org> <94FA376D-8F43-4327-B4E6-8E4BF06C7D60@gmail.com> <CFA40702822144168203534F70552EA9@buildpc> <31CE6896-F796-4C6D-BE00-51EBE281294E@gmail.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Z4JKYhKgiKyoVmFH9NmuRcmJo_k
Cc: "ipsec@ietf.org WG" <ipsec@ietf.org>
Subject: Re: [IPsec] IPsec Digest, Vol 125, Issue 9
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Sep 2014 13:27:16 -0000

On Tue, 9 Sep 2014, Les Leposo wrote:

> Sure, CPU and RAM are not as expensive as "fast-path" or SA "tables" typical found in servers with hardware acceleration - prior to this proposal,
> these expensive resources were (typically) reserved only after authentication (and child SA nego succeeded).

No one is telling you to enable this by default.

> However, with this proposal, the server will be allocating these resources anyhow because it can't judge between a good vs. bad client.

In the same way as you cannot judge between different half-open IKE
connections. Nothing really changes, and a few (tens of thousands) of
lines in the SADB shouldn't be that hard on a kernel. Clearly you won't
enable this on your embedded $20 router.

>       And the server could always limit the number of unauthenticated connections
> 
> absolutely, it would help the server implementors, if this proposal required such safe guards- others would be rate-limiting and perhaps shorter
> Child-SA lifetimes.

Resource management depends on local resources. Therefor these are
typically left for local policy to decide. Is there any reason to
do that differently here?

>             2) this feature could also tempt network admins to fallback to 'null authentication' as a work-around/short-cut in cases
>             where they are unable to properly configure a deployment.
>
>       The Security Considerations must strongly discourage to do it.
> 
> Concur.

Do our security considerations state not to use "secret" as a PSK? Sure,
we should give some sane security advise, but we shouldn't talk about
obviously stupid things to do like purposefully degrading your security.

> Concur, the sensor data would have to be inconsequential.
> 
> Because even when the measurement is not secret, a rogue "sensor" could easily pollute the central data which could be bad especially if the data
> is consequently used to control e.g. the cooling plant.

That still assumes neither party authenticates. There is a big
difference between one-sided authentication (like most ssh and tls)
and no authentication (like most port 80)

Paul


From nobody Tue Sep  9 09:24:04 2014
Return-Path: <dharmanandana.pothulam@huawei.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6CE1A6FEE for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 09:24:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.852
X-Spam-Level: 
X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l27_-WXN6XI2 for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 09:24:00 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55A371A6FF0 for <ipsec@ietf.org>; Tue,  9 Sep 2014 09:23:58 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMJ38782; Tue, 09 Sep 2014 16:23:56 +0000 (GMT)
Received: from SZXEML450-HUB.china.huawei.com (10.82.67.193) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 9 Sep 2014 17:23:55 +0100
Received: from SZXEML513-MBX.china.huawei.com ([169.254.7.135]) by szxeml450-hub.china.huawei.com ([10.82.67.193]) with mapi id 14.03.0158.001; Wed, 10 Sep 2014 00:23:44 +0800
From: dharmanandana pothulam <dharmanandana.pothulam@huawei.com>
To: "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: IKEv1 Interop issue: Transform number mismatch
Thread-Index: Ac/MMUaa+S917NfETdW/SJOAFJT6kw==
Date: Tue, 9 Sep 2014 16:23:44 +0000
Message-ID: <3F00A55B1B111141BAE547DB25D09FE254570D36@szxeml513-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.152.68]
Content-Type: multipart/alternative; boundary="_000_3F00A55B1B111141BAE547DB25D09FE254570D36szxeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/DNUsP-vu7F8ZCSYOwhJBV4Ow2CE
Cc: Sameer varshney <sameer.varshney@huawei.com>, Liangjicheng <liangjicheng@huawei.com>
Subject: [IPsec] IKEv1 Interop issue: Transform number mismatch
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Sep 2014 16:24:03 -0000

--_000_3F00A55B1B111141BAE547DB25D09FE254570D36szxeml513mbxchi_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi All,



We are facing one IKEv1 interop issue. The issue is that Responder (checkpo=
int SeGW) not retaining the

transform numbers received from the initiator (huawei base station), SeGW r=
eplies with its own transform number.



IKEv1 First & second packets:

Initiator                                                     Responder
-------------                                                -------------
VID, SA         ------------------------------>                            =
(1)

            <-----------------------------             VID, SA             =
(2)



In our scenario, Huawei base station(Initiator) sending transform number as=
 0 and Checkpoint security gateway(Responder)

is replying with 1, And Initiator trying to match transform number received=
 from the responder with one of the numbers sent

initially and negotiation failing due to mismatch.



We did Interop test with Cisco and Juniper, Cisco and Juniper is retaining =
the transform numbers sent by the Huawei base station,

and negotiation successful.



Huawei base station compares received transform number with one of the tran=
sform numbers sent initially along with other attributes,

this is inline with the RFC 2408 section 4.2 statement (The initiator MUST =
verify that the Security Association payload received from

the responder matches one of the proposals sent initially).



One more point rfc says =93The responder SHOULD retain the Proposal # field=
 in the Proposal payload and the

Transform # field in each Transform payload of the selected Proposal".



As I understand This transform number helps to direct to the correct SA att=
ributes in initiator side.



why some vendors not retaining the transform number sent by initiator? if n=
ot followed, Do we see usefulness of the transform

number received at initiator side? Can we drop the exchange if correct tran=
sform number not received?



Regards,

Dharma.







--_000_3F00A55B1B111141BAE547DB25D09FE254570D36szxeml513mbxchi_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html dir=3D"ltr">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<style id=3D"owaParaStyle">P {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body fPStyle=3D"1" ocsi=3D"0">
<div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: =
10pt;">
<p>Hi All,</p>
<p>&nbsp;</p>
<p><font face=3D"Times New Roman">We are facing one IKEv1 interop&nbsp;issu=
e. The issue is that&nbsp;Responder&nbsp;</font><span style=3D"FONT-FAMILY:=
 'Times New Roman','serif'; FONT-SIZE: 10.5pt; mso-bidi-font-size: 12.0pt; =
mso-fareast-font-family: &#23435;&#20307;; mso-font-kerning: 1.0pt; mso-ans=
i-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA"><=
font size=3D"2">(checkpoint
 SeGW) not retaining the </font></span></p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"><font size=3D"2">transform
 numbers received from the initiator (huawei base station),&nbsp;SeGW repli=
es&nbsp;with its own transform number.</font></span></p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"><font size=3D"2"></font></span>&nbsp;</p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA">IKEv1 First &amp; second
 packets:</span></p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"><br>
Initiator&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;Responder<br>
-------------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;-------------<br>
VID, SA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;--------------=
----------------&gt;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; (1)</span></p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&lt;-----------------------------&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;VID,
 SA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;(2)</span></p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"><font size=3D"2"></font></span>&nbsp;</p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"><font size=3D"2">In our
 scenario, Huawei base station(Initiator) sending transform number as 0 and=
 Checkpoint security gateway(Responder)
</font></span></p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"><font size=3D"2">is replying
 with 1,&nbsp;</font></span><span style=3D"FONT-FAMILY: 'Times New Roman','=
serif'; FONT-SIZE: 10.5pt; mso-bidi-font-size: 12.0pt; mso-fareast-font-fam=
ily: &#23435;&#20307;; mso-font-kerning: 1.0pt; mso-ansi-language: EN-US; m=
so-fareast-language: ZH-CN; mso-bidi-language: AR-SA"><font size=3D"2">And
 Initiator trying to match transform number received from the responder wit=
h one of the numbers sent
</font></span></p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"><font size=3D"2">initially
 and negotiation failing due to mismatch.</font></span></p>
<p>&nbsp;</p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"><font size=3D"2">We did&nbsp;Interop
 test with Cisco and Juniper, Cisco and Juniper is retaining the transform =
numbers sent by the Huawei base station,
</font></span></p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"><font size=3D"2">and
 negotiation successful.&nbsp;</font></span></p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"><font size=3D"2"></font></span>&nbsp;</p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"><font size=3D"2">Huawei
 base station compares received&nbsp;transform number&nbsp;with one of the&=
nbsp;transform numbers&nbsp;sent initially along with other attributes,&nbs=
p;</font></span></p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"><font size=3D"2">this
 is inline with the&nbsp;RFC 2408 section 4.2 statement (<span><em>The init=
iator MUST verify that the Security Association payload received from
</em></span></font></span></p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"><font size=3D"2"><span><em>the
 responder matches one of the proposals sent initially)</em></span>. </font=
></span><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 1=
0.5pt; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307=
;; mso-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language:=
 ZH-CN; mso-bidi-language: AR-SA"></span></p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"></span>&nbsp;</p>
<p><font size=3D"2"><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; =
FONT-SIZE: 10.5pt; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#2=
3435;&#20307;; mso-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-farea=
st-language: ZH-CN; mso-bidi-language: AR-SA">One
 more point&nbsp;rfc says&nbsp;</span><span style=3D"FONT-FAMILY: 'Times Ne=
w Roman','serif'; FONT-SIZE: 10.5pt; mso-bidi-font-size: 12.0pt; mso-fareas=
t-font-family: &#23435;&#20307;; mso-font-kerning: 1.0pt; mso-ansi-language=
: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA">=93<i style=
=3D"mso-bidi-font-style: normal">The
 responder SHOULD retain the Proposal # field in the Proposal payload and t=
he </i>
</span></font></p>
<p><font size=3D"2"><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; =
FONT-SIZE: 10.5pt; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#2=
3435;&#20307;; mso-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-farea=
st-language: ZH-CN; mso-bidi-language: AR-SA"><i style=3D"mso-bidi-font-sty=
le: normal">Transform
 # field in each Transform payload of the selected Proposal&quot;.&nbsp; </=
i></span></font></p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"><em><font size=3D"2"></font></em></span>&nbsp;=
</p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"><font size=3D"2">As I
 understand This transform number helps to direct to the correct SA attribu=
tes in initiator side.
</font></span></p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"><font size=3D"2"></font></span>&nbsp;</p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"><font size=3D"2">why
 some&nbsp;vendors&nbsp;not&nbsp;retaining the transform number sent by ini=
tiator?&nbsp;if not followed, Do we see&nbsp;usefulness of the transform
</font></span></p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"><font size=3D"2">number
 received at initiator side?&nbsp;C</font></span><span style=3D"FONT-FAMILY=
: 'Times New Roman','serif'; FONT-SIZE: 10.5pt; mso-bidi-font-size: 12.0pt;=
 mso-fareast-font-family: &#23435;&#20307;; mso-font-kerning: 1.0pt; mso-an=
si-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA">=
<font size=3D"2">an
 we drop the exchange if correct transform number not received?</font></spa=
n></p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"><font size=3D"2"></font></span>&nbsp;</p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"><span style=3D"FONT-FAMILY: 'Times New Roman',=
'serif'; FONT-SIZE: 10.5pt; mso-bidi-font-size: 12.0pt; mso-fareast-font-fa=
mily: &#23435;&#20307;; mso-font-kerning: 1.0pt; mso-ansi-language: EN-US; =
mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA">Regards,</span></p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA">Dharma.</span></p>
<p><span style=3D"FONT-FAMILY: 'Times New Roman','serif'; FONT-SIZE: 10.5pt=
; mso-bidi-font-size: 12.0pt; mso-fareast-font-family: &#23435;&#20307;; ms=
o-font-kerning: 1.0pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-C=
N; mso-bidi-language: AR-SA"></span></span>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
</div>
</body>
</html>

--_000_3F00A55B1B111141BAE547DB25D09FE254570D36szxeml513mbxchi_--


From nobody Tue Sep  9 13:37:18 2014
Return-Path: <grbartle@cisco.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC241A016B for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 13:37:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.153
X-Spam-Level: 
X-Spam-Status: No, score=-16.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfAWntvRx1BA for <ipsec@ietfa.amsl.com>; Tue,  9 Sep 2014 13:37:16 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B0131A0149 for <ipsec@ietf.org>; Tue,  9 Sep 2014 13:37:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8256; q=dns/txt; s=iport; t=1410295036; x=1411504636; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=4EUUaf/DGBQe2X7Bu/UjfHD3FbMEMjAWej+eQQ3KPsg=; b=mvFphgPKrURk/BM7b0ZkshVB6kbwn1722IXLBdMwuWP3D2EkJ1hHyn0G pnvnWmGJjrY7tal06YYzLCtJsiqFqLEYlARaNxRFJTCxpE+bGGIipTNkb ZGAg/0zPVvY8mT3hGKMfo8LvgUZrBR1abkz6w0tulLPPCFu0PRRmCfBRJ A=;
X-Files: smime.p7s : 3708
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AioFAD9kD1StJA2H/2dsb2JhbABQCYJqI1NXBMocCodMAYENFniEAwEBAQQBAQEaURcEAgEIDgMEAQEBLgIfBgsdCAIEARIOiCADEQEMtkENhl0BEwSNIIFSCgEBNCIGhEYFjyyCFYIGgUqFUoIQjnOGO4NhbIEPOYEHAQEB
X-IronPort-AV: E=Sophos;i="5.04,493,1406592000";  d="p7s'?scan'208";a="353849229"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP; 09 Sep 2014 20:37:15 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s89KbFgo025248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Sep 2014 20:37:15 GMT
Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Tue, 9 Sep 2014 15:37:15 -0500
From: "Graham Bartlett (grbartle)" <grbartle@cisco.com>
To: Valery Smyslov <svanru@gmail.com>, Yaron Sheffer <yaronf.ietf@gmail.com>,  ipsec <ipsec@ietf.org>
Thread-Topic: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2Protocol
Thread-Index: AQHPyy4DFcwTtQ+4VEqN7XrYpOOjUZv33bCAgACGbgmAAUXHgA==
Date: Tue, 9 Sep 2014 20:37:15 +0000
Message-ID: <D0351ADC.2C641%grbartle@cisco.com>
References: <540CA9B2.3090807@gmail.com> <DCC36F8DE78A4E5280A9977B4CAC144A@buildpc> <D033575C.2C348%grbartle@cisco.com> <0666BB9DE8304DC1891658BFA9FF7EF7@buildpc>
In-Reply-To: <0666BB9DE8304DC1891658BFA9FF7EF7@buildpc>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
x-originating-ip: [10.55.146.103]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3493143433_11713542"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/NNDEjuaXfwzhWIEateT7yC-I7U8
Subject: Re: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2Protocol
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Sep 2014 20:37:18 -0000

--B_3493143433_11713542
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Hi

Thanks for the clarifications.

I really like the idea of this - as Daniel has said it's well suited for
IoT, but I'm wondering if this could then lend IKEv2 into a similar
concept as 'https' - secure channel and authentication of the headend and
then initiators credentials are sent by some other means..

As you say I think it needs a lot of thought into the security
considerations.


cheers

On 09/09/2014 08:11, "Valery Smyslov" <svanru@gmail.com> wrote:

>Hi Graham,
>
>> I have one Q.
>> 
>> If endpoint receives a request to create an unauthenticated IKE SA
>> from the IP address, which is configured on the endpoint to be
>> authenticated, the request SHOULD be rejected.
>> 
>> Why is this not MUST be rejected ? Otherwise an attacker could trick the
>> responder into revealing their identity (maybe some words around this
>> also?).
>
>I was thinking of two possible cases here.
>First, even if the initiator was able to certify its identity,
>it might want to keep anonymity for this particular
>connection (for example to prevent tracking its
>activity). And the other case - the responder's configuration
>could be out of date and the IP address it was
>configured to be authenticated could already
>belong to some other, anonymous host.
>
>Anyway, while SHOULD is pretty strong requirement,
>it is not ultimate here: I'm not absolutely sure
>that the above cases completely justify it over MUST.
>We can discuss it.
>
>And you are right - some (I dare to say "many")
>words still need to be added into the Security Considerations
>section.
>
>Regards,
>Valery.
>
>
>> Thanks
>> 
>> Graham
>> 
>> 
>> On 08/09/2014 07:27, "Valery Smyslov" <svanru@gmail.com> wrote:
>> 
>>>Yes.
>>>
>>>Obviously, as the author of the document I can see its value,
>>>which is describet in the document itself.
>>>And I think it's better to standardize it with
>>>more people involved, than as individual submission.
>>>
>>>Regards,
>>>Valery.
>>>
>>>----- Original Message -----
>>>From: "Yaron Sheffer" <yaronf.ietf@gmail.com>
>>>To: "ipsec" <ipsec@ietf.org>
>>>Sent: Sunday, September 07, 2014 10:53 PM
>>>Subject: [IPsec] Call for adoption: The NULL Authentication Method in
>>>IKEv2Protocol
>>>
>>>
>>>> Dear working group,
>>>>
>>>> This is a call for adopting draft-smyslov-ipsecme-ikev2-null-auth as a
>>>>WG 
>>>> document. Please respond to this mail with a Yes or No and a short
>>>> rationale, at latest by Friday Sep. 12.
>>>>
>>>> Thanks,
>>>> Yaron
>>>>
>>>> _______________________________________________
>>>> IPsec mailing list
>>>> IPsec@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>
>>>_______________________________________________
>>>IPsec mailing list
>>>IPsec@ietf.org
>>>https://www.ietf.org/mailman/listinfo/ipsec
>>

--B_3493143433_11713542
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIOeAYJKoZIhvcNAQcCoIIOaTCCDmUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgggw+MIIEpzCCA4+gAwIBAgIQZmBP5MZi1b5ckUheWh5wbTANBgkqhkiG9w0BAQUFADBU
MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xv
YmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMB4XDTE0MDEyNTIyNDE0OFoXDTE2MDYw
MzExMDA1OFowQDEbMBkGA1UEAwwSZ3JiYXJ0bGVAY2lzY28uY29tMSEwHwYJKoZIhvcNAQkB
FhJncmJhcnRsZUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCq
YhYxolKrFoPfXuZTQdAiQVFg14EvWwIEMyXxhfH2RiwOSJRSsUVmTNYG8HdeSf0JdzjAMh9p
ODgxLC90Q1nbLyBqmEAKElWTasAnATKBCD7aLhce+25cznTT4FDpJsvvU2lZFPWXSLQm3bNR
+mEDP6pd8zR1ItOKBlNmGtwypUUvi4KrKRPzx1cSgVTN0Xocj4fC5N8Rj3tOqOns+EHOX4Rw
oy/rebHjQyv1cRr6FyGhRuz24hPv8mAGr/iF0cMphAsujaGKyAo+tA05K3nI0fdoeCx2wdEs
vo8jIeeZVii07b3K9+VdJQmerVKJyMfQT6gLkyuassY/5aXlglNxAgMBAAGjggGHMIIBgzAO
BgNVHQ8BAf8EBAMCBaAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYm
aHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wHQYDVR0RBBYwFIESZ3Ji
YXJ0bGVAY2lzY28uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF
BwMEMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3Nw
ZXJzb25hbHNpZ24xZzIuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDov
L3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24xZzIuY3J0MB0G
A1UdDgQWBBRBHvZ1Aur9AFGMEId10iH6yeUX3jAfBgNVHSMEGDAWgBTsrJjMJ3KTz1YyzSPH
nY1FhfQiAzANBgkqhkiG9w0BAQUFAAOCAQEAdhq5YZv5ZCu0/HdQF1S3f+quesVc39HKv+Fe
2rmKuJcxfGOFZGpKhJDa1+sFeN/T+e2e6UJ0Yy90GLqi5U1fioD3XRhsFiVOh7CbJQESF2Xx
U1bhdutZFh6Ythe28iRPY6HQjJ/7ke5IQBWvLnAbCIzgy0GgZB9Vj+a2z6bzmfR6KAuLaMqM
vahvJ0w+DeHMEOVnVzCdZzHMaEOXZHw/uZj5/hGvkp2C0rH/LhGunfAPX12WhVQSsgxWJhaF
8D49Ymrt7PWBsLokx06/15XwY2ogBmfLmeN/WhMy5HUiLn3EnzwF+RK2MStCDpP5AWzdnrTR
tM43+AJrHwoI7H+C9DCCBBYwggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUA
MFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdS
b290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcN
MTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1z
YTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGjx0+LH0uRqeZCHrYQ7KN3QuahfxY8
fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqDlin3HracDqMRgwrknWuFeqxh
N2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQBhcaJA2ucABbUVTHDTxi
7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+OhtnAhrgzrsd4oAy
qgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7upoxvV09Fsf7h
DeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/
AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUdIAAw
NDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w
MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAf
BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7un
yEtmt9Ia7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDu
vg/OZ0gILDFIa9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVU
m5V1tW3XuYNg6SbtcDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVg
wb/j/kplOa13nshhc8zULVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5ui
B8TZ0s327g44Ylc6dgKgYelNn9RLYjNETX8OIJZlr0tFYpcYrDCCA3UwggJdoAMCAQICCwQA
AAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i
YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJv
b3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJCRTEZ
MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS
R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7m
mY3Oo+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsur
HExwB6E9CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8G
PIhpWypNxadUuGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounI
Cjjr8iQTT3NUkxOFOhu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjI
GSvRRqpI1mQq14M0/ywqwWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8B
Af8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8
/UswDQYJKoZIhvcNAQEFBQADggEBANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16q
EUi25Qijs8o9YU3TRgmzPsOg42NVG/K676054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeY
BN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8suWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUM
HaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRWMZXQZ4mFK/lspl1GnQyqguSZUd1wt9tW
PWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY24GzBBzFH6SAbxUgyd4MiAod1mZV
4vxIySkmaeAxggH+MIIB+gIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT
aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzIC
EGZgT+TGYtW+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgtYD6
nK95H3RTpDpOaxOdt+d2X+znG6MD9lq6JB2gsfkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNMTQwOTA5MjAzNzEzWjANBgkqhkiG9w0BAQEFAASCAQAsPCUT
mMudfMmHOgiUkFm7emPwgZVopQMd9Uclt5rcIo6V0QDM/KljUWbxAuoVOzdYv9me7sGF6xnH
KhRz3LxKYnNKpuJv0r6hc38+sXbDArSNWGw6Ks/1nQfl3VsY7YtkHsilL1Rx0iinsdQnHcBm
DGNWx/L24rYrIBflnKQDodx6GzUYFdFfpJ19UjaSpcJy567wtoQM7hA/+Aq24cZBywGMwk3d
7eJAQZO9I8j8zYFaenCtlb8wq3ejjFQhp+VoNVhsR/ovgxPR2HufGwJH71dNXV1A6EUh60qR
4WfQqva4iqSOnjVl50Z9W/x+XQSVXldQITPl3crs2++bMzs7

--B_3493143433_11713542--


From nobody Wed Sep 10 01:57:01 2014
Return-Path: <ynir@checkpoint.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4CC1A06B1 for <ipsec@ietfa.amsl.com>; Wed, 10 Sep 2014 01:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.552
X-Spam-Level: 
X-Spam-Status: No, score=-8.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsR2sxw-CM7o for <ipsec@ietfa.amsl.com>; Wed, 10 Sep 2014 01:56:55 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C211A06A8 for <ipsec@ietf.org>; Wed, 10 Sep 2014 01:56:53 -0700 (PDT)
x-m-msg: CPCHECK
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s8A8uDhx004970; Wed, 10 Sep 2014 11:56:13 +0300
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.44]) by IL-EX10.ad.checkpoint.com ([169.254.2.162]) with mapi id 14.03.0181.006; Wed, 10 Sep 2014 11:56:13 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: dharmanandana pothulam <dharmanandana.pothulam@huawei.com>, "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: IKEv1 Interop issue: Transform number mismatch
Thread-Index: Ac/MMUaa+S917NfETdW/SJOAFJT6kwAo5M0g
Date: Wed, 10 Sep 2014 08:56:12 +0000
Message-ID: <4613980CFC78314ABFD7F85CC3027721548B3EE6@DAG-EX10.ad.checkpoint.com>
References: <3F00A55B1B111141BAE547DB25D09FE254570D36@szxeml513-mbx.china.huawei.com>
In-Reply-To: <3F00A55B1B111141BAE547DB25D09FE254570D36@szxeml513-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [194.29.34.193]
x-kse-antivirus-interceptor-info: protection disabled
x-cpdlp: 11817a21379325079c4b7686ace07a0ce6fdd396ca
Content-Type: multipart/alternative; boundary="_000_4613980CFC78314ABFD7F85CC3027721548B3EE6DAGEX10adcheckp_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/QxCDIgpx_sLJcBvpLJyngb6N1v0
Cc: Sameer varshney <sameer.varshney@huawei.com>, Liangjicheng <liangjicheng@huawei.com>
Subject: Re: [IPsec] IKEv1 Interop issue: Transform number mismatch
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Sep 2014 08:56:59 -0000

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

Hi, Dharma.

This mailing list is intended for discussion of standards, not the conforma=
nce (or lack thereof) of particular implementations.

I will contact you off-list

Yoav

From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of dharmanandana poth=
ulam
Sent: Tuesday, September 09, 2014 7:24 PM
To: ipsec@ietf.org
Cc: Sameer varshney; Liangjicheng
Subject: [IPsec] IKEv1 Interop issue: Transform number mismatch


Hi All,



We are facing one IKEv1 interop issue. The issue is that Responder (checkpo=
int SeGW) not retaining the

transform numbers received from the initiator (huawei base station), SeGW r=
eplies with its own transform number.



IKEv1 First & second packets:

Initiator                                                     Responder
-------------                                                -------------
VID, SA         ------------------------------>                            =
(1)

            <-----------------------------             VID, SA             =
(2)



In our scenario, Huawei base station(Initiator) sending transform number as=
 0 and Checkpoint security gateway(Responder)

is replying with 1, And Initiator trying to match transform number received=
 from the responder with one of the numbers sent

initially and negotiation failing due to mismatch.



We did Interop test with Cisco and Juniper, Cisco and Juniper is retaining =
the transform numbers sent by the Huawei base station,

and negotiation successful.



Huawei base station compares received transform number with one of the tran=
sform numbers sent initially along with other attributes,

this is inline with the RFC 2408 section 4.2 statement (The initiator MUST =
verify that the Security Association payload received from

the responder matches one of the proposals sent initially).



One more point rfc says "The responder SHOULD retain the Proposal # field i=
n the Proposal payload and the

Transform # field in each Transform payload of the selected Proposal".



As I understand This transform number helps to direct to the correct SA att=
ributes in initiator side.



why some vendors not retaining the transform number sent by initiator? if n=
ot followed, Do we see usefulness of the transform

number received at initiator side? Can we drop the exchange if correct tran=
sform number not received?



Regards,

Dharma.








Email secured by Check Point.



Email secured by Check Point

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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi, Dharma.<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">This mailing list is inte=
nded for discussion of standards, not the conformance (or lack thereof) of =
particular implementations.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I will contact you off-li=
st<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Yoav
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> IPsec [m=
ailto:ipsec-bounces@ietf.org]
<b>On Behalf Of </b>dharmanandana pothulam<br>
<b>Sent:</b> Tuesday, September 09, 2014 7:24 PM<br>
<b>To:</b> ipsec@ietf.org<br>
<b>Cc:</b> Sameer varshney; Liangjicheng<br>
<b>Subject:</b> [IPsec] IKEv1 Interop issue: Transform number mismatch<o:p>=
</o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;san=
s-serif&quot;;color:black">Hi All,<o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;san=
s-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;color:black">We are facing one IKEv1 int=
erop&nbsp;issue. The issue is that&nbsp;Responder&nbsp;</span><span style=
=3D"font-size:10.0pt;color:black;mso-fareast-language:ZH-CN">(checkpoint Se=
GW) not retaining the
</span><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot=
;sans-serif&quot;;color:black"><o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;color:black;mso-fareast-language:ZH-CN">=
transform numbers received from the initiator (huawei base station),&nbsp;S=
eGW replies&nbsp;with its own transform number.</span><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:blac=
k"><o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;san=
s-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p>
<p><span style=3D"font-size:10.5pt;color:black;mso-fareast-language:ZH-CN">=
IKEv1 First &amp; second packets:</span><span style=3D"font-size:10.0pt;fon=
t-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:black"><o:p></o:p>=
</span></p>
<p><span style=3D"font-size:10.5pt;color:black;mso-fareast-language:ZH-CN">=
<br>
Initiator&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;Responder<br>
-------------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;-------------<br>
VID, SA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;--------------=
----------------&gt;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; (1)</span><span style=3D"font-size:10.0pt;font-=
family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:black"><o:p></o:p></=
span></p>
<p><span style=3D"font-size:10.5pt;color:black;mso-fareast-language:ZH-CN">=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt=
;-----------------------------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;VID, SA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(2)</span><span style=3D"font-si=
ze:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:black=
"><o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;san=
s-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;color:black;mso-fareast-language:ZH-CN">=
In our scenario, Huawei base station(Initiator) sending transform number as=
 0 and Checkpoint security gateway(Responder)
</span><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot=
;sans-serif&quot;;color:black"><o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;color:black;mso-fareast-language:ZH-CN">=
is replying with 1,&nbsp;And Initiator trying to match transform number rec=
eived from the responder with one of the numbers sent
</span><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot=
;sans-serif&quot;;color:black"><o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;color:black;mso-fareast-language:ZH-CN">=
initially and negotiation failing due to mismatch.</span><span style=3D"fon=
t-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:b=
lack"><o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;san=
s-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;color:black;mso-fareast-language:ZH-CN">=
We did&nbsp;Interop test with Cisco and Juniper, Cisco and Juniper is retai=
ning the transform numbers sent by the Huawei base station,
</span><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot=
;sans-serif&quot;;color:black"><o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;color:black;mso-fareast-language:ZH-CN">=
and negotiation successful.&nbsp;</span><span style=3D"font-size:10.0pt;fon=
t-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:black"><o:p></o:p>=
</span></p>
<p><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;san=
s-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;color:black;mso-fareast-language:ZH-CN">=
Huawei base station compares received&nbsp;transform number&nbsp;with one o=
f the&nbsp;transform numbers&nbsp;sent initially along with other attribute=
s,&nbsp;</span><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quo=
t;,&quot;sans-serif&quot;;color:black"><o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;color:black;mso-fareast-language:ZH-CN">=
this is inline with the&nbsp;RFC 2408 section 4.2 statement (<em>The initia=
tor MUST verify that the Security Association payload received from
</em></span><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,=
&quot;sans-serif&quot;;color:black"><o:p></o:p></span></p>
<p><em><span style=3D"font-size:10.0pt;color:black;mso-fareast-language:ZH-=
CN">the responder matches one of the proposals sent initially)</span></em><=
span style=3D"font-size:10.0pt;color:black;mso-fareast-language:ZH-CN">.
</span><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot=
;sans-serif&quot;;color:black"><o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;san=
s-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p>
<p><span style=3D"font-size:10.5pt;color:black;mso-fareast-language:ZH-CN">=
One more point&nbsp;rfc says&nbsp;&#8220;<i>The responder SHOULD retain the=
 Proposal # field in the Proposal payload and the
</i></span><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&=
quot;sans-serif&quot;;color:black"><o:p></o:p></span></p>
<p><i><span style=3D"font-size:10.5pt;color:black;mso-fareast-language:ZH-C=
N">Transform # field in each Transform payload of the selected Proposal&quo=
t;.&nbsp;
</span></i><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&=
quot;sans-serif&quot;;color:black"><o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;san=
s-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;color:black;mso-fareast-language:ZH-CN">=
As I understand This transform number helps to direct to the correct SA att=
ributes in initiator side.
</span><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot=
;sans-serif&quot;;color:black"><o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;san=
s-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;color:black;mso-fareast-language:ZH-CN">=
why some&nbsp;vendors&nbsp;not&nbsp;retaining the transform number sent by =
initiator?&nbsp;if not followed, Do we see&nbsp;usefulness of the transform
</span><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot=
;sans-serif&quot;;color:black"><o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;color:black;mso-fareast-language:ZH-CN">=
number received at initiator side?&nbsp;Can we drop the exchange if correct=
 transform number not received?</span><span style=3D"font-size:10.0pt;font-=
family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:black"><o:p></o:p></=
span></p>
<p><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;san=
s-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p>
<p><span style=3D"font-size:10.5pt;color:black;mso-fareast-language:ZH-CN">=
Regards,<o:p></o:p></span></p>
<p><span style=3D"font-size:10.5pt;color:black;mso-fareast-language:ZH-CN">=
Dharma.<o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;san=
s-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;san=
s-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p>
<p><span style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;san=
s-serif&quot;;color:black">&nbsp;<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>
<br>
Email secured by Check Point. <br>
<br>
<br>
<br>
Email secured by Check Point <o:p></o:p></p>
</div>
</body>
</html>

--_000_4613980CFC78314ABFD7F85CC3027721548B3EE6DAGEX10adcheckp_--


From nobody Wed Sep 10 08:42:34 2014
Return-Path: <sgundave@cisco.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7ACA1A8734 for <ipsec@ietfa.amsl.com>; Wed, 10 Sep 2014 08:42:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.152
X-Spam-Level: 
X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8R-ELZK6S-x for <ipsec@ietfa.amsl.com>; Wed, 10 Sep 2014 08:42:30 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262481A872F for <ipsec@ietf.org>; Wed, 10 Sep 2014 08:42:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24492; q=dns/txt; s=iport; t=1410363750; x=1411573350; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=a03E+yCTYoD3dTEU/5bx3eDGujgK51GUVfIzG9QX8P0=; b=CjBMKd9+8cxp+zIPzkXf41s2RmMdtGjKWlPUdE1C7+GCRKyNjR7e5g6Y 7h3+1n7QvKt3deXQEJliJZ49a6Y6EVGECWIfglob8VhhHWeTT1MfmIyOz 9qDgxQ082kHxqlLvWKKtE2iegFCk2ETgj3rDDhLpilmROg2J2zrOS2lqW 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlUFANlwEFStJV2S/2dsb2JhbABZgkdGU1cEyFaBaodKAYEQFniEBAIESSgIEgEIEiYHORQDDgIEAQ0FiEINvmMBF45rEQFNAwYBCYRDBY8sghWEMII8hEaBX40KhkWDYWwBAYENOYEHAQEB
X-IronPort-AV: E=Sophos; i="5.04,499,1406592000"; d="scan'208,217"; a="76691793"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP; 10 Sep 2014 15:42:27 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8AFgR5s030837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 15:42:27 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 10:42:27 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>, "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: Review of draft-gundavelli-ipsecme-3gpp-ims-options-02
Thread-Index: AQHPzQ3SKMQYWriGR/e+ppRj0kUPVQ==
Date: Wed, 10 Sep 2014 15:42:26 +0000
Message-ID: <D035BCAE.162A5C%sgundave@cisco.com>
In-Reply-To: <39B5E4D390E9BD4890E2B310790061011272E731@ESESSMB301.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.32.246.210]
Content-Type: multipart/alternative; boundary="_000_D035BCAE162A5Csgundaveciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/-AfT8cxBJSyoDIzR56dt9bEaQr4
Cc: "Aeneas Dodd-Noble \(noblea\)" <noblea@cisco.com>, Jouni Korhonen <jouni.nospam@gmail.com>, "baboescu@broadcom.com" <baboescu@broadcom.com>
Subject: Re: [IPsec] Review of draft-gundavelli-ipsecme-3gpp-ims-options-02
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Sep 2014 15:42:32 -0000

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

Hi Ivo,

Thanks for your response. Please see inline.


On 9/9/14 4:09 AM, "Ivo Sedlacek" <ivo.sedlacek@ericsson.com<mailto:ivo.sed=
lacek@ericsson.com>> wrote:

Hello,

I reviewed http://tools.ietf.org/id/draft-gundavelli-ipsecme-3gpp-ims-optio=
ns-02.txt and found the following issues:

ISSUE 1: the draft states:
------
These attributes can be
   used for carrying the IPv4 and IPv6 address of the Proxy-Call Control
   and Service function (P-CSCF).
------
In 3GPP, P-CSCF abbreviation stands for "Proxy-Call Session Control Functio=
n".

PROPOSAL 1: state:
------
These attributes can be
   used for carrying the IPv4 address and IPv6 address of the Proxy-Call Se=
ssion Control function (P-CSCF).
------


Ok




ISSUE 2: the draft states:
------
When an IPSec gateway delivers these
   attributes to an IPsec client, it can obtain the IPv4 and/or IPv6
   address of the P-CSCF server located in the home network.
------
The P-CSCF does not necessarily need to be located in the home network. In =
roaming situations, the P-CSCF can also be in visited network.
Example: User has a contract with an European operator. The user with its u=
ser equipment (UE) is in Japan and uses network of a Japanese operator. In =
such use case, the ePDG entity, the PGW entity and P-CSCF can all be in vis=
ited network (i.e. Japanese operator network).

PROPOSAL 2: state:
------
When an IPSec gateway delivers these
   attributes to an IPsec client, the IPsec client can obtain the IPv4 and/=
or IPv6
   address of the P-CSCF server located in the 3GPP network.
------

The "home" network terminology was not truly intended to reflect the 3GPP r=
oaming architecture. Its just to say the configuration comes from the PGW/L=
MA.

But, agree with the change.



ISSUE 3: the draft states:
------
   The Third Generation Partnership Project (3GPP) S2b reference point
   [TS23402], specified by the 3GPP system architecture defines a
   mechanism for allowing a mobile node (MN) attached in an untrusted
   non-3GPP IP Access Network to securely connect to the 3GPP home
   network and access IP services.
------
When roaming, the UE can access IP services in the 3GPP home network or 3GP=
P visited network. ePDG can be in visited or home network - see  http://www=
.3gpp.org/ftp/Specs/archive/23_series/23.402/23402-c50.zip section 4.5.4. I=
f so, P-GW and P-CSCF can also be in the visited network.

PROPOSAL 3: state:
------
   The Third Generation Partnership Project (3GPP) S2b reference point
   [TS23402], specified by the 3GPP system architecture defines a
   mechanism for allowing a mobile node (MN) attached in an untrusted
   non-3GPP IP Access Network to securely connect to a 3GPP
   network and access IP services.
------


The "home" network terminology was not truly intended to reflect the 3GPP r=
oaming architecture. Its just to say the configuration comes from the PGW/L=
MA.

But, agree with the change.




ISSUE 4: the draft states:
------
   A mobile node in this scenario may potentially need to access the IP
   Multimedia Subsystem (IMS) services in the home network.
------
P-CSCF can also be in visited network.

PROPOSAL 4: state:
------
   A mobile node in this scenario may potentially need to access the IP
   Multimedia Subsystem (IMS) services in the 3GPP network.
------



Ok




ISSUE 5: the draft states:
------
   Proxy-Call Session Control Function (P-CSCF)

      The P-CSCF is the entry point to the 3GPP IMS (IP Multimedia
      Subsystem) domain and serves as the outbound proxy server for the
      mobile node.  The mobile node attaches to the P-CSCF prior to
      performing IMS registrations and initiating SIP sessions.
------
Problems:
1) 3GPP IMS is not a domain.
2) The mobile node does NOT attach to P-CSCF prior to performing the IMS re=
gistration. Instead, the registration with IMS is the request for "attachme=
nt" to IMS.

PROPOSAL 5: state:
------
   Proxy-Call Session Control Function (P-CSCF)

      The P-CSCF is the entry point to the 3GPP IMS (IP Multimedia
      Subsystem)  and serves as the SIP outbound proxy for the
      mobile node.  The mobile node performs SIP registration to 3GPP IMS a=
nd initiates SIP sessions via a P-CSCF.
------


Thanks. That was a typo. It should have said, "the mobile node attaches to =
the 3GPP network ...".

Agree with the text.




ISSUE 6: the draft states:
------
Multiple P-CSCF
   servers MAY be requested by including a single instance of an empty
   P-CSCF_IP4_ADDRESS attribute with zero-length IPv4 Address field.
   The responder MAY respond with zero or more P-CSCF_IP4_ADDRESS
   attributes, and there is no implied order in the response.
------
IMO, the 1st sentence above is misleading as it suggests that the mobile no=
de has a choise to request one P-CSCF IPv4 address or to request multiple P=
-CSCF IPv4 addresses. However, in my reading of the rest of the draft, the =
mobile node has just one choise - request P-CSCF IPv4 addresses and receive=
 zero, one or several P-CSCF IPv4 addresses.

PROPOSAL 6: state:
------
If an instance of an empty
   P-CSCF_IP4_ADDRESS attribute with zero-length IPv4 Address field is incl=
uded by mobile node, the responder MAY respond with zero, one or more P-CSC=
F_IP4_ADDRESS
   attributes. If several P-CSCF_IP4_ADDRESS attributes are provided in one=
 IKEv2 message, there is no implied order among the P-CSCF_IP4_ADDRESS attr=
ibutes.
------


The proposed text is very clear. Thank you




ISSUE 7: the draft states:
------
Multiple P-CSCF
   servers MAY be requested by including a single instance of an empty
   P-CSCF_IP6_ADDRESS attribute with zero-length IPv6 Address field.
   The responder MAY respond with zero or more P-CSCF_IP6_ADDRESS
   attributes, and there is no implied order in the response.
------
IMO, the 1st sentence above is misleading as it suggests that the mobile no=
de has a choise to request one P-CSCF IPv6 address or to request multiple P=
-CSCF IPv6 addresses. However, in my reading of the rest of the draft, the =
mobile node has just one choise - request P-CSCF IPv6 addresses and receive=
 zero, one or several P-CSCF IPv6 addresses.

PROPOSAL 7: state:
------
If an instance of an empty
   P-CSCF_IP6_ADDRESS attribute with zero-length IPv6 Address field is incl=
uded by mobile node, the responder MAY respond with zero, one or more P-CSC=
F_IP6_ADDRESS
   attributes. If several P-CSCF_IP6_ADDRESS attributes are provided in one=
 IKEv2 message, there is no implied order among the P-CSCF_IP6_ADDRESS attr=
ibutes.
------

The proposed text is very clear. Thank you



Thanks for a detailed review.

Regards
Sri




Kind regards

Ivo Sedlacek
Ericsson
Mobile +420 608 234 709
ivo.sedlacek@ericsson.com<mailto:ivo.sedlacek@ericsson.com>
www.ericsson.com

This Communication is Confidential. We only send and receive email on the b=
asis of the terms set out at www.ericsson.com/email_disclaimer


--_000_D035BCAE162A5Csgundaveciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <04972B2235F1034A9D62BE977D3621DC@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; font-size: 14px; font-family: Calibri, sans-ser=
if; ">
<div style=3D"color: rgb(0, 0, 0); ">Hi Ivo,</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); ">Thanks for your response. Please see i=
nline.</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); ">On 9/9/14 4:09 AM, &quot;Ivo Sedlacek&=
quot; &lt;<a href=3D"mailto:ivo.sedlacek@ericsson.com">ivo.sedlacek@ericsso=
n.com</a>&gt; wrote:</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"color: rgb(0=
, 0, 0); border-left-color: rgb(181, 196, 223); border-left-width: 5px; bor=
der-left-style: solid; padding-top: 0px; padding-right: 0px; padding-bottom=
: 0px; padding-left: 5px; margin-top: 0px; margin-right: 0px; margin-bottom=
: 0px; margin-left: 5px; ">
<div>Hello,</div>
<div><br>
</div>
<div>I reviewed <a href=3D"http://tools.ietf.org/id/draft-gundavelli-ipsecm=
e-3gpp-ims-options-02.txt">
http://tools.ietf.org/id/draft-gundavelli-ipsecme-3gpp-ims-options-02.txt</=
a> and found the following issues:</div>
<div><br>
</div>
<div>ISSUE 1: the draft states:</div>
<div>------</div>
<div>These attributes can be</div>
<div>&nbsp;&nbsp; used for carrying the IPv4 and IPv6 address of the Proxy-=
Call Control</div>
<div>&nbsp;&nbsp; and Service function (P-CSCF).</div>
<div>------</div>
<div>In 3GPP, P-CSCF abbreviation stands for &quot;Proxy-Call Session Contr=
ol Function&quot;.</div>
</blockquote>
<blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"color: rgb(0=
, 0, 0); border-left-color: rgb(181, 196, 223); border-left-width: 5px; bor=
der-left-style: solid; padding-top: 0px; padding-right: 0px; padding-bottom=
: 0px; padding-left: 5px; margin-top: 0px; margin-right: 0px; margin-bottom=
: 0px; margin-left: 5px; ">
<div><br>
</div>
<div>PROPOSAL 1: state:</div>
<div>------</div>
<div>These attributes can be</div>
<div>&nbsp;&nbsp; used for carrying the IPv4 address and IPv6 address of th=
e Proxy-Call Session Control function (P-CSCF).</div>
<div>------</div>
</blockquote>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div><b><font class=3D"Apple-style-span" color=3D"#007f00">Ok</font></b></d=
iv>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"color: rgb(0=
, 0, 0); border-left-color: rgb(181, 196, 223); border-left-width: 5px; bor=
der-left-style: solid; padding-top: 0px; padding-right: 0px; padding-bottom=
: 0px; padding-left: 5px; margin-top: 0px; margin-right: 0px; margin-bottom=
: 0px; margin-left: 5px; ">
<div><br>
</div>
<div>ISSUE 2: the draft states:</div>
<div>------</div>
<div>When an IPSec gateway delivers these</div>
<div>&nbsp;&nbsp; attributes to an IPsec client, it can obtain the IPv4 and=
/or IPv6</div>
<div>&nbsp;&nbsp; address of the P-CSCF server located in the home network.=
</div>
<div>------</div>
<div>The P-CSCF does not necessarily need to be located in the home network=
. In roaming situations, the P-CSCF can also be in visited network.&nbsp;&n=
bsp;</div>
<div>Example: User has a contract with an European operator. The user with =
its user equipment (UE) is in Japan and uses network of a Japanese operator=
. In such use case, the ePDG entity, the PGW entity and P-CSCF can all be i=
n visited network (i.e. Japanese
 operator network).</div>
<div><br>
</div>
<div>PROPOSAL 2: state:</div>
<div>------</div>
<div>When an IPSec gateway delivers these</div>
<div>&nbsp;&nbsp; attributes to an IPsec client, the IPsec client can obtai=
n the IPv4 and/or IPv6</div>
<div>&nbsp;&nbsp; address of the P-CSCF server located in the 3GPP network.=
</div>
<div>------</div>
</blockquote>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div>
<div><b><font class=3D"Apple-style-span" color=3D"#007f00">The &quot;home&q=
uot; network terminology was not truly intended to reflect the 3GPP roaming=
 architecture. Its just to say the configuration comes from the PGW/LMA.&nb=
sp;</font></b></div>
<div><b><font class=3D"Apple-style-span" color=3D"#007f00"><br>
</font></b></div>
<div><b><font class=3D"Apple-style-span" color=3D"#007f00">But, agree with =
the change.</font></b></div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
</div>
<blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"color: rgb(0=
, 0, 0); border-left-color: rgb(181, 196, 223); border-left-width: 5px; bor=
der-left-style: solid; padding-top: 0px; padding-right: 0px; padding-bottom=
: 0px; padding-left: 5px; margin-top: 0px; margin-right: 0px; margin-bottom=
: 0px; margin-left: 5px; ">
<div><br>
</div>
<div>ISSUE 3: the draft states:</div>
<div>------</div>
<div>&nbsp;&nbsp; The Third Generation Partnership Project (3GPP) S2b refer=
ence point</div>
<div>&nbsp;&nbsp; [TS23402], specified by the 3GPP system architecture defi=
nes a</div>
<div>&nbsp;&nbsp; mechanism for allowing a mobile node (MN) attached in an =
untrusted</div>
<div>&nbsp;&nbsp; non-3GPP IP Access Network to securely connect to the 3GP=
P home</div>
<div>&nbsp;&nbsp; network and access IP services.</div>
<div>------</div>
<div>When roaming, the UE can access IP services in the 3GPP home network o=
r 3GPP visited network. ePDG can be in visited or home network - see&nbsp;&=
nbsp;<a href=3D"http://www.3gpp.org/ftp/Specs/archive/23_series/23.402/2340=
2-c50.zip">http://www.3gpp.org/ftp/Specs/archive/23_series/23.402/23402-c50=
.zip</a>
 section 4.5.4. If so, P-GW and P-CSCF can also be in the visited network.<=
/div>
</blockquote>
<blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"color: rgb(0=
, 0, 0); border-left-color: rgb(181, 196, 223); border-left-width: 5px; bor=
der-left-style: solid; padding-top: 0px; padding-right: 0px; padding-bottom=
: 0px; padding-left: 5px; margin-top: 0px; margin-right: 0px; margin-bottom=
: 0px; margin-left: 5px; ">
<div><br>
</div>
<div>PROPOSAL 3: state:</div>
<div>------</div>
<div>&nbsp;&nbsp; The Third Generation Partnership Project (3GPP) S2b refer=
ence point</div>
<div>&nbsp;&nbsp; [TS23402], specified by the 3GPP system architecture defi=
nes a</div>
<div>&nbsp;&nbsp; mechanism for allowing a mobile node (MN) attached in an =
untrusted</div>
<div>&nbsp;&nbsp; non-3GPP IP Access Network to securely connect to a 3GPP =
</div>
<div>&nbsp;&nbsp; network and access IP services.</div>
<div>------</div>
</blockquote>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div><b><font class=3D"Apple-style-span" color=3D"#007f00"><br>
</font></b></div>
<div>
<div><b><font class=3D"Apple-style-span" color=3D"#007f00">The &quot;home&q=
uot; network terminology was not truly intended to reflect the 3GPP roaming=
 architecture. Its just to say the configuration comes from the PGW/LMA.
</font></b></div>
<div><b><font class=3D"Apple-style-span" color=3D"#007f00"><br>
</font></b></div>
<div>
<div><b><font class=3D"Apple-style-span" color=3D"#007f00">But, agree with =
the change.</font></b></div>
</div>
</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"color: rgb(0=
, 0, 0); border-left-color: rgb(181, 196, 223); border-left-width: 5px; bor=
der-left-style: solid; padding-top: 0px; padding-right: 0px; padding-bottom=
: 0px; padding-left: 5px; margin-top: 0px; margin-right: 0px; margin-bottom=
: 0px; margin-left: 5px; ">
<div><br>
</div>
<div>ISSUE 4: the draft states:</div>
<div>------</div>
<div>&nbsp;&nbsp; A mobile node in this scenario may potentially need to ac=
cess the IP</div>
<div>&nbsp;&nbsp; Multimedia Subsystem (IMS) services in the home network.<=
/div>
<div>------</div>
<div>P-CSCF can also be in visited network.</div>
<div><br>
</div>
<div>PROPOSAL 4: state:</div>
<div>------</div>
<div>&nbsp;&nbsp; A mobile node in this scenario may potentially need to ac=
cess the IP</div>
<div>&nbsp;&nbsp; Multimedia Subsystem (IMS) services in the 3GPP network.<=
/div>
<div>------</div>
</blockquote>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div><b><font class=3D"Apple-style-span" color=3D"#007f00">Ok</font></b></d=
iv>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"color: rgb(0=
, 0, 0); border-left-color: rgb(181, 196, 223); border-left-width: 5px; bor=
der-left-style: solid; padding-top: 0px; padding-right: 0px; padding-bottom=
: 0px; padding-left: 5px; margin-top: 0px; margin-right: 0px; margin-bottom=
: 0px; margin-left: 5px; ">
<div><br>
</div>
<div>ISSUE 5: the draft states:</div>
<div>------</div>
<div>&nbsp;&nbsp; Proxy-Call Session Control Function (P-CSCF)</div>
<div><br>
</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The P-CSCF is the entry point to t=
he 3GPP IMS (IP Multimedia</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Subsystem) domain and serves as th=
e outbound proxy server for the</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mobile node.&nbsp;&nbsp;The mobile=
 node attaches to the P-CSCF prior to</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;performing IMS registrations and i=
nitiating SIP sessions.</div>
<div>------</div>
<div>Problems:</div>
<div>1) 3GPP IMS is not a domain.</div>
<div>2) The mobile node does NOT attach to P-CSCF prior to performing the I=
MS registration. Instead, the registration with IMS is the request for &quo=
t;attachment&quot; to IMS.</div>
<div><br>
</div>
<div>PROPOSAL 5: state:</div>
<div>------</div>
<div>&nbsp;&nbsp; Proxy-Call Session Control Function (P-CSCF)</div>
<div><br>
</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The P-CSCF is the entry point to t=
he 3GPP IMS (IP Multimedia</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Subsystem)&nbsp;&nbsp;and serves a=
s the SIP outbound proxy for the</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mobile node.&nbsp;&nbsp;The mobile=
 node performs SIP registration to 3GPP IMS and initiates SIP sessions via =
a P-CSCF.</div>
<div>------</div>
</blockquote>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div><b><font class=3D"Apple-style-span" color=3D"#007f00">Thanks. That was=
 a typo. It should have said, &quot;the mobile node attaches to the 3GPP ne=
twork ...&quot;.</font></b></div>
<div><b><font class=3D"Apple-style-span" color=3D"#007f00"><br>
</font></b></div>
<div><b><font class=3D"Apple-style-span" color=3D"#007f00">Agree with the t=
ext.</font></b></div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"color: rgb(0=
, 0, 0); border-left-color: rgb(181, 196, 223); border-left-width: 5px; bor=
der-left-style: solid; padding-top: 0px; padding-right: 0px; padding-bottom=
: 0px; padding-left: 5px; margin-top: 0px; margin-right: 0px; margin-bottom=
: 0px; margin-left: 5px; ">
<div><br>
</div>
<div>ISSUE 6: the draft states:</div>
<div>------</div>
<div>Multiple P-CSCF</div>
<div>&nbsp;&nbsp; servers MAY be requested by including a single instance o=
f an empty</div>
<div>&nbsp;&nbsp; P-CSCF_IP4_ADDRESS attribute with zero-length IPv4 Addres=
s field.</div>
<div>&nbsp;&nbsp; The responder MAY respond with zero or more P-CSCF_IP4_AD=
DRESS</div>
<div>&nbsp;&nbsp; attributes, and there is no implied order in the response=
.</div>
<div>------</div>
<div>IMO, the 1st sentence above is misleading as it suggests that the mobi=
le node has a choise to request one P-CSCF IPv4 address or to request multi=
ple P-CSCF IPv4 addresses. However, in my reading of the rest of the draft,=
 the mobile node has just one choise
 - request P-CSCF IPv4 addresses and receive zero, one or several P-CSCF IP=
v4 addresses.</div>
<div><br>
</div>
<div>PROPOSAL 6: state:</div>
<div>------</div>
<div>If an instance of an empty</div>
<div>&nbsp;&nbsp; P-CSCF_IP4_ADDRESS attribute with zero-length IPv4 Addres=
s field is included by mobile node, the responder MAY respond with zero, on=
e or more P-CSCF_IP4_ADDRESS</div>
<div>&nbsp;&nbsp; attributes. If several P-CSCF_IP4_ADDRESS attributes are =
provided in one IKEv2 message, there is no implied order among the P-CSCF_I=
P4_ADDRESS attributes.</div>
<div>------</div>
</blockquote>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div><b><font class=3D"Apple-style-span" color=3D"#007f00">The proposed tex=
t is very clear. Thank you</font></b></div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"color: rgb(0=
, 0, 0); border-left-color: rgb(181, 196, 223); border-left-width: 5px; bor=
der-left-style: solid; padding-top: 0px; padding-right: 0px; padding-bottom=
: 0px; padding-left: 5px; margin-top: 0px; margin-right: 0px; margin-bottom=
: 0px; margin-left: 5px; ">
<div><br>
</div>
<div>ISSUE 7: the draft states:</div>
<div>------</div>
<div>Multiple P-CSCF</div>
<div>&nbsp;&nbsp; servers MAY be requested by including a single instance o=
f an empty</div>
<div>&nbsp;&nbsp; P-CSCF_IP6_ADDRESS attribute with zero-length IPv6 Addres=
s field.</div>
<div>&nbsp;&nbsp; The responder MAY respond with zero or more P-CSCF_IP6_AD=
DRESS</div>
<div>&nbsp;&nbsp; attributes, and there is no implied order in the response=
.</div>
<div>------</div>
<div>IMO, the 1st sentence above is misleading as it suggests that the mobi=
le node has a choise to request one P-CSCF IPv6 address or to request multi=
ple P-CSCF IPv6 addresses. However, in my reading of the rest of the draft,=
 the mobile node has just one choise
 - request P-CSCF IPv6 addresses and receive zero, one or several P-CSCF IP=
v6 addresses.</div>
<div><br>
</div>
<div>PROPOSAL 7: state:</div>
<div>------</div>
<div>If an instance of an empty</div>
<div>&nbsp;&nbsp; P-CSCF_IP6_ADDRESS attribute with zero-length IPv6 Addres=
s field is included by mobile node, the responder MAY respond with zero, on=
e or more P-CSCF_IP6_ADDRESS</div>
<div>&nbsp;&nbsp; attributes. If several P-CSCF_IP6_ADDRESS attributes are =
provided in one IKEv2 message, there is no implied order among the P-CSCF_I=
P6_ADDRESS attributes.</div>
<div>------</div>
</blockquote>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div>
<div><b><font class=3D"Apple-style-span" color=3D"#007f00">The proposed tex=
t is very clear. Thank you</font></b></div>
</div>
<div><b><font class=3D"Apple-style-span" color=3D"#007f00"><br>
</font></b></div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); ">Thanks for a detailed review.</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); ">Regards</div>
<div style=3D"color: rgb(0, 0, 0); ">Sri</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<div style=3D"color: rgb(0, 0, 0); "><br>
</div>
<blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"color: rgb(0=
, 0, 0); border-left-color: rgb(181, 196, 223); border-left-width: 5px; bor=
der-left-style: solid; padding-top: 0px; padding-right: 0px; padding-bottom=
: 0px; padding-left: 5px; margin-top: 0px; margin-right: 0px; margin-bottom=
: 0px; margin-left: 5px; ">
<div><br>
</div>
<div>Kind regards</div>
<div><br>
</div>
<div>Ivo Sedlacek</div>
<div>Ericsson</div>
<div>Mobile &#43;420 608 234 709</div>
<div><a href=3D"mailto:ivo.sedlacek@ericsson.com">ivo.sedlacek@ericsson.com=
</a></div>
<div>www.ericsson.com</div>
<div><br>
</div>
<div>This Communication is Confidential. We only send and receive email on =
the basis of the terms set out at www.ericsson.com/email_disclaimer</div>
<div><br>
</div>
</blockquote>
</body>
</html>

--_000_D035BCAE162A5Csgundaveciscocom_--


From nobody Wed Sep 10 20:56:32 2014
Return-Path: <rahul.stds@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1779E1A0389 for <ipsec@ietfa.amsl.com>; Wed, 10 Sep 2014 20:56:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRToQhkTDGjG for <ipsec@ietfa.amsl.com>; Wed, 10 Sep 2014 20:56:28 -0700 (PDT)
Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D15EF1A0348 for <ipsec@ietf.org>; Wed, 10 Sep 2014 20:56:28 -0700 (PDT)
Received: by mail-pd0-f177.google.com with SMTP id y10so4636760pdj.8 for <ipsec@ietf.org>; Wed, 10 Sep 2014 20:56:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=IUKyE8+gg3vmpIGslwzG3rO3O/QolePREZsAlAJR6YA=; b=dlZ0F6q6EhJuqHxULDpfL52kGOP1lTiFt6MnLrRrG4ZG47nLfdFID8UwGboce5ClBn OZDdfW0SdABqOv07ih7UU4jBcYjMtA1h2QJXpmKbffnnlgtKG6BCCeQ/rZdLtaNksrt/ pipD1YeeooC5C2A9QJkgVQswsSxV/NDdlpnAXkOGCTjd38XoKPXVC0Kjt1/mr7IqbRjU G+h6oJxQC1bTKz7Mbn1ya2iXPZyuOaWdVPXo6qZiU3PKV/uNQ8pdBKldNoAo1sP1+a3f vSalNkmTCp3m6CzMxH+iPNhQ/WyN/+OedGcrvjC1heX+hHXIr8R1mKoCbpuSoSVR40XB qJSQ==
MIME-Version: 1.0
X-Received: by 10.68.236.227 with SMTP id ux3mr1667295pbc.159.1410407788527; Wed, 10 Sep 2014 20:56:28 -0700 (PDT)
Received: by 10.70.82.101 with HTTP; Wed, 10 Sep 2014 20:56:28 -0700 (PDT)
Date: Thu, 11 Sep 2014 09:26:28 +0530
Message-ID: <CAEX11nYFEj-f8m-8fK-j7FH-EDavG0XgmJwonFMj_V_5eJHFzQ@mail.gmail.com>
From: Rahul Vaidya <rahul.stds@gmail.com>
To: ipsec@ietf.org
Content-Type: multipart/alternative; boundary=047d7b33d6fa3946f70502c227b3
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/VqXMhz_SJfpNAGXzE4NBWSJ9-Dc
Subject: [IPsec] Mandatory Public Key based authentication with EAP
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Sep 2014 03:56:30 -0000

--047d7b33d6fa3946f70502c227b3
Content-Type: text/plain; charset=UTF-8

Dear IPsec Experts,

In RFC 4306, 5996 as well as draft-kivinen-ipsecme-ikev2-rfc5996bis, there
is a statement:

"An implementation using EAP MUST also use a public-key-based
authentication of the server to the client before the EAP exchange begins,
even if the EAP method offers mutual authentication."

RFC 5998 which updates 5996 says:
"This document specifies how EAP methods that provide mutual authentication
and key agreement can be used to provide extensible responder
authentication for IKEv2 based on methods other than public key signatures."

The 2 statements are contradictory, given the 'MUST' requirement for public
-key based authentication in RFC 5996.

I request a view from the IPsec community on whether public key based
authentication can be avoided without impacting the security of the
connection/network.

Regards,
Rahul Vaidya

--047d7b33d6fa3946f70502c227b3
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><div><div>Dear IPsec Experts,<br><br></div>In RFC 4306, 5996 as well as draft-kivinen-ipsecme-ikev2-rfc5996bis, there is a statement:<br><br>&quot;An implementation using EAP MUST also use a public-key-based
   authentication of the server to the client before the EAP exchange
   begins, even if the EAP method offers mutual authentication.&quot;<br><br></div>RFC 5998 which updates 5996 says:<br>&quot;This document specifies how EAP methods that provide mutual
   authentication and key agreement can be used to provide extensible
   responder authentication for IKEv2 based on methods other than public
   key signatures.&quot;<br><div><br></div><div>The 2 statements are contradictory, given the &#39;MUST&#39; requirement for public -key based authentication in RFC 5996.<br><br></div><div>I
 request a view from the IPsec community on whether public key based 
authentication can be avoided without impacting the security of the 
connection/network.<br><br>Regards,<br>Rahul Vaidya</div></div>

--047d7b33d6fa3946f70502c227b3--


From nobody Wed Sep 10 21:02:34 2014
Return-Path: <hugokraw@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30DAA1A0389 for <ipsec@ietfa.amsl.com>; Wed, 10 Sep 2014 21:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9g54AkufH3De for <ipsec@ietfa.amsl.com>; Wed, 10 Sep 2014 21:02:15 -0700 (PDT)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC3BF1A0348 for <ipsec@ietf.org>; Wed, 10 Sep 2014 21:02:14 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id gi9so11065114lab.30 for <ipsec@ietf.org>; Wed, 10 Sep 2014 21:02:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Axv8E4r8I46jKqVyJcEh9npdf8Z5Hxq1GrStg+bQ3ls=; b=0dg1pgLYVPxW399pcgXMbQi832W0OHW63O9ZVv5P5ofLRsCHnGYxQ9izeJMcRwW4jH UfoSFrLjO+kbQj140aUtxj5YsIF9ZrFWEzUr1JBhdHUzOhklQg5p4x2zTXYI28YLcYu0 iAn+greT+XJhRntxJ1mzrU6mZKHe9JW3AsHeklRGl4qDTDhFV95SAOaUdejr7T3PjuZS NG5ig3AWUTqQuzQYzxeHzv3wVu8xF1zR+9/rE05l/ZRbETAHC26cHnkTA/Bzth8q666c YyRQdHctwym0OBGWPv0SL0ymzgeJzDbYcSSPkErcyS3eH5Dd2yHF2XJAqVdZG87zh0+M t3zw==
X-Received: by 10.112.209.37 with SMTP id mj5mr222405lbc.55.1410408133034; Wed, 10 Sep 2014 21:02:13 -0700 (PDT)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by 10.25.16.135 with HTTP; Wed, 10 Sep 2014 21:01:41 -0700 (PDT)
In-Reply-To: <6E9345DD1E9A43158A0DD61F96C09741@buildpc>
References: <540CA9B2.3090807@gmail.com> <BE175F90-68B6-4731-B32E-BA9EF3F3BAD8@dell.com> <CADi0yUM3ESC9A1WaJJZ5QKrAeUd-wiNLFRdpRUYp5vGXir-A6Q@mail.gmail.com> <6E9345DD1E9A43158A0DD61F96C09741@buildpc>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Thu, 11 Sep 2014 00:01:41 -0400
X-Google-Sender-Auth: poEohaD6eG8ey6h0-QPE6u550wQ
Message-ID: <CADi0yUMQftcsij+aH5XB2O97LZ7fVJeq2jNTHqK5kvsaZuSWYQ@mail.gmail.com>
To: Valery Smyslov <svanru@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c266d8c2098f0502c23be8
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/BjaYxy33hNVR9Y3K1dMhjHLSmBE
Cc: IPsecme WG <ipsec@ietf.org>, Paul_Koning@dell.com
Subject: Re: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Sep 2014 04:02:19 -0000

--001a11c266d8c2098f0502c23be8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I didn't know (or remember) that IKEv2 allows for different directional
authentication mechanisms.
In any case, as a general rule, the fact that two methods are secure,
doesn't mean that mix-and-match-ing them (or taking a subset) is still
secure.
Particularly for IKEv2, I do not know of any work that has shown such
security.

Hugo

On Tue, Sep 9, 2014 at 7:58 AM, Valery Smyslov <svanru@gmail.com> wrote:

>  Hi Hugo,
>
> The subject line (and the comment on Bellovin attack) caught my eye. I
> don't follow the discussions in this list so I don't know how much the ne=
ed
> and dangers of unauthenticated methods were discussed here. I want to poi=
nt
> out that (and probably many did before me) that un-authentication is a ve=
ry
> tricky option especially in a protocol that was created with mutual
> authentication as a core requirement and assumption. I can see potential
> benefits and uses but I can also see it abused and misused (the internet
> draft doesn't do too good a job warning about it but even if it did, peop=
le
> will misuse it).
>
> I agree that the draft's Security Consideration section in its current
> form is incomplete.
> And I hope that if the draft is adopted then it will draw an attention of
> many people,
> who will help to improve the Security Considerations to list all the
> caveats,
> to make all possible warning and to give advice how to safely use this
> mode.
>
> But requirements aside, I cannot vow for the security of IKE's key
> exchange in a one-way authentication mode. No one (that I know, definitel=
y
> not me) designed this protocol to support one-way authentication. So the
> question of whether it is secure in this setting has not been investigate=
d.
> Moreover, I see that the draft uses shared-key fields for theanonymous si=
de
> of the communication and, I imagine, the other can use signature-based
> authentication. What security properties do you get from that mix-and-mat=
ch
> authentication methods?
>
>  IKEv2 currently allows the peers to use different authentication methods=
.
> So, if one of the peers uses preshared key, while the other uses
> digital signature, then it is considered legal and secure from
> protocol's design point of view. If the peer, using preshared key in this
> scenario,
> uses key, known to everyone, then we will get one-way authentication
> with the current IKEv2. The next step, that the draft does - get rid of
> well-known preshared key and compute the content of the AUTH Payload
> the same way it is computed currently in IKEv2 when it is used
> with non key generating EAP methods - using SK_pi (or SK_Pr) as the key
> I believe the draft doesn't change the way cryptography is used in IKEv2.
>
> One likely misuse of this technique is that people will use
> unauthenticated (or one-way) IKE and will run some other authentication o=
n
> top of it (say, password based or whatever). Well, protocols do not
> necessarily compose securely. TLS had many failures like that (BEAST,
> re-negotiation, triple handshake, ...) and IPsec saw examples of that in
> the combinations of unauthenticated ESP and AH. IKE's cryptographic desig=
n
> has endured the test of time but these variations (or improvisations)
> endanger it.
>
> Well, sometimes mutual authentication is impossible or undesirable.
> Sometimes privacy is more important and people are ready to
> sacrifice some level of security to keep their privacy.
> And sometimes the choice is - either use plaintext
> or unauthenticated encryption. The latter at least
> prevents passive eavesdropping...
>
> Finally, since Bellovin's attack was mentioned, I want to make sure that
> no one is thinking of not using the MAC authentication at the IP packet
> level, right?
>
> Absolutely.
>
> Hugo
>
> Regards,
> Valery Smyslov.
>
> On Mon, Sep 8, 2014 at 10:54 AM, <Paul_Koning@dell.com> wrote:
>
>>
>> On Sep 7, 2014, at 2:53 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
>>
>> > Dear working group,
>> >
>> > This is a call for adopting draft-smyslov-ipsecme-ikev2-null-auth as a
>> WG document. Please respond to this mail with a Yes or No and a short
>> rationale, at latest by Friday Sep. 12.
>>
>> Maybe.
>>
>> I understand and support the rationale for this draft.
>>
>> The Security Considerations seems to be inadequate.  Whenever possible,
>> real authentication should be used.  So the Security Considerations shou=
ld
>> explicitly and strongly emphasize that, and recommend that products that
>> incorporate Null authentication should strive to avoid its use whenever
>> possible, and steer users away from its use when they can.
>>
>> A related question: does the use of Null authentication open up the
>> Bellovin attack?  It seems that it would.  If so, my answer changes to =
=E2=80=9CNO=E2=80=9D.
>>
>>         paul
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>
>  ------------------------------
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>

--001a11c266d8c2098f0502c23be8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:verdana,=
sans-serif;font-size:small">I didn&#39;t know (or remember) that IKEv2 allo=
ws for different directional authentication mechanisms.<br></div><div class=
=3D"gmail_default" style=3D"font-family:verdana,sans-serif;font-size:small"=
>In any case, as a general rule, the fact that two methods are secure, does=
n&#39;t mean that mix-and-match-ing them (or taking a subset) is still secu=
re.<br></div><div class=3D"gmail_default" style=3D"font-family:verdana,sans=
-serif;font-size:small">Particularly for IKEv2, I do not know of any work t=
hat has shown such security.<br><br></div><div class=3D"gmail_default" styl=
e=3D"font-family:verdana,sans-serif;font-size:small">Hugo<br></div></div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Sep 9, 2014=
 at 7:58 AM, Valery Smyslov <span dir=3D"ltr">&lt;<a href=3D"mailto:svanru@=
gmail.com" target=3D"_blank">svanru@gmail.com</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><u></u>





<div bgcolor=3D"#ffffff">
<div><font>Hi Hugo,</font></div><span class=3D"">
<blockquote style=3D"BORDER-LEFT:#000000 2px solid;PADDING-LEFT:5px;PADDING=
-RIGHT:0px;MARGIN-LEFT:5px;MARGIN-RIGHT:0px">
  <div>The subject line (and the comment on Bellovin attack) caught my eye.=
 I=20
  don&#39;t follow the discussions in this list so I don&#39;t know how muc=
h the need=20
  and dangers of unauthenticated methods were discussed here. I want to poi=
nt=20
  out that (and probably many did before me) that un-authentication is a ve=
ry=20
  tricky option especially in a protocol that was created with mutual=20
  authentication as a core requirement and assumption. I can see potential=
=20
  benefits and uses but I can also see it abused and misused (the internet =
draft=20
  doesn&#39;t do too good a job warning about it but even if it did, people=
 will=20
  misuse it).</div></blockquote>
</span><div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=
=3D"gmail_default"><font face=3D"Arial">I agree that the draft&#39;s Securi=
ty=20
Consideration section in its current form is incomplete.</font></div>
<div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=3D"gmai=
l_default"><font face=3D"Arial">And I hope that if the draft is=20
adopted then it will draw an attention of many people,</font></div>
<div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=3D"gmai=
l_default"><font face=3D"Arial">who will help to improve the=20
Security Considerations=C2=A0to list all the caveats,</font></div>
<div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=3D"gmai=
l_default"><font face=3D"Arial">to make all possible warning and to=20
give advice how to safely use this mode.</font></div>
<blockquote style=3D"BORDER-LEFT:#000000 2px solid;PADDING-LEFT:5px;PADDING=
-RIGHT:0px;MARGIN-LEFT:5px;MARGIN-RIGHT:0px">
  <div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" dir=3D"ltr"=
 class=3D"gmail_default">But requirements aside, I cannot vow for the secur=
ity of=20
  IKE&#39;s key exchange in a one-way authentication mode. No one (that I k=
now,=20
  definitely not me) designed this protocol to support one-way authenticati=
on.=20
  So the question of whether it is secure in this setting has not been=20
  investigated. Moreover, I see that the draft uses shared-key fields for=
=20
  theanonymous side of the communication and, I imagine, the other can use=
=20
  signature-based authentication. What security properties do you get from =
that=20
  mix-and-match authentication methods? </div></blockquote>
<div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=3D"gmai=
l_default"><font face=3D"Arial">
<div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=3D"gmai=
l_default"><font face=3D"Arial"><font face=3D"Arial">IKEv2=20
currently allows the peers to use different authentication methods.</font>=
=20
<div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=3D"gmai=
l_default"><font face=3D"Arial">So, if one of the peers uses=20
preshared key, while the other uses </font></div>
<div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=3D"gmai=
l_default"><font face=3D"Arial">digital signature, then it is=20
considered legal and secure from</font></div>
<div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=3D"gmai=
l_default"><font face=3D"Arial">protocol&#39;s design point of view. If=20
the peer, using preshared key in this scenario,</font></div>
<div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=3D"gmai=
l_default"><font face=3D"Arial">uses key, known to=20
everyone,=C2=A0then we will get one-way authentication</font></div>
<div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=3D"gmai=
l_default"><font face=3D"Arial">with the current IKEv2. The next=20
step, that the draft does - get rid of </font></div>
<div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=3D"gmai=
l_default"><font face=3D"Arial">well-known preshared key and compute=20
the content of the AUTH Payload</font></div>
<div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=3D"gmai=
l_default"><font face=3D"Arial">the same way it is computed=20
currently in IKEv2 when it is used</font></div>
<div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=3D"gmai=
l_default"><font face=3D"Arial">with non key generating EAP methods=20
- using SK_pi (or SK_Pr) as the key</font></div>
<div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=3D"gmai=
l_default"><font face=3D"Arial">I believe the draft doesn&#39;t=20
</font><font face=3D"Arial">change the way cryptography is used in=20
IKEv2.</font></div></font></div></font></div><span class=3D"">
<blockquote style=3D"BORDER-LEFT:#000000 2px solid;PADDING-LEFT:5px;PADDING=
-RIGHT:0px;MARGIN-LEFT:5px;MARGIN-RIGHT:0px">
  <div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" dir=3D"ltr"=
 class=3D"gmail_default">One likely misuse of this technique is that people=
 will=20
  use unauthenticated (or one-way) IKE and will run some other authenticati=
on on=20
  top of it (say, password based or whatever). Well, protocols do not=20
  necessarily compose securely. TLS had many failures like that (BEAST,=20
  re-negotiation, triple handshake, ...) and IPsec saw examples of that in =
the=20
  combinations of unauthenticated ESP and AH. IKE&#39;s cryptographic desig=
n has=20
  endured the test of time but these variations (or improvisations) endange=
r=20
  it.</div></blockquote>
</span><div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=
=3D"gmail_default"><font face=3D"Arial"></font><font face=3D"Arial">Well,=
=20
sometimes mutual authentication is impossible or undesirable.</font></div>
<div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=3D"gmai=
l_default"><font face=3D"Arial">Sometimes privacy is more important=20
and people are ready to</font></div>
<div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=3D"gmai=
l_default"><font face=3D"Arial">sacrifice some level of security to=20
keep their privacy.</font></div>
<div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=3D"gmai=
l_default"><font face=3D"Arial">And sometimes the choice is - either=20
use plaintext</font></div>
<div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=3D"gmai=
l_default"><font face=3D"Arial">or unauthenticated encryption. The=20
latter at least</font></div>
<div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=3D"gmai=
l_default"><font face=3D"Arial">prevents passive=20
eavesdropping...</font></div><span class=3D"">
<blockquote style=3D"BORDER-LEFT:#000000 2px solid;PADDING-LEFT:5px;PADDING=
-RIGHT:0px;MARGIN-LEFT:5px;MARGIN-RIGHT:0px">
  <div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" dir=3D"ltr"=
 class=3D"gmail_default">Finally, since Bellovin&#39;s attack was mentioned=
, I want to=20
  make sure that no one is thinking of not using the MAC authentication at =
the=20
  IP packet level, right? </div></blockquote>
</span><div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" class=
=3D"gmail_default"><font face=3D"Arial">Absolutely.</font></div><font></fon=
t>
<blockquote style=3D"BORDER-LEFT:#000000 2px solid;PADDING-LEFT:5px;PADDING=
-RIGHT:0px;MARGIN-LEFT:5px;MARGIN-RIGHT:0px">
  <div>Hugo</div></blockquote>
<div><font>Regards,</font></div>
<div><font>Valery Smyslov.</font></div>
<blockquote style=3D"BORDER-LEFT:#000000 2px solid;PADDING-LEFT:5px;PADDING=
-RIGHT:0px;MARGIN-LEFT:5px;MARGIN-RIGHT:0px"><span class=3D"">
  <div style=3D"FONT-FAMILY:verdana,sans-serif;FONT-SIZE:small" dir=3D"ltr"=
 class=3D"gmail_default">On Mon, Sep 8, 2014 at 10:54 AM, <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:Paul_Koning@dell.com" target=3D"_blank">Paul_Koning@=
dell.com</a>&gt;</span> wrote:<br></div>
  <div dir=3D"ltr" class=3D"gmail_extra">
  <div class=3D"gmail_quote">
  <blockquote style=3D"BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;=
PADDING-LEFT:1ex" class=3D"gmail_quote"><span><font></font><font></font><fo=
nt></font><br>On Sep 7, 2014, at 2:53 PM, Yaron Sheffer &lt;<a href=3D"mail=
to:yaronf.ietf@gmail.com" target=3D"_blank">yaronf.ietf@gmail.com</a>&gt;=
=20
    wrote:<br><br>&gt; Dear working group,<br>&gt;<br>&gt; This is a call f=
or=20
    adopting draft-smyslov-ipsecme-ikev2-null-auth as a WG document. Please=
=20
    respond to this mail with a Yes or No and a short rationale, at latest =
by=20
    Friday Sep. 12.<br><br></span>Maybe.<br><br>I understand and support th=
e=20
    rationale for this draft.<br><br>The Security Considerations seems to b=
e=20
    inadequate.=C2=A0 Whenever possible, real authentication should be=20
    used.=C2=A0 So the Security Considerations should explicitly and strong=
ly=20
    emphasize that, and recommend that products that incorporate Null=20
    authentication should strive to avoid its use whenever possible, and st=
eer=20
    users away from its use when they can.<br><br>A related question: does =
the=20
    use of Null authentication open up the Bellovin attack?=C2=A0 It seems =
that=20
    it would.=C2=A0 If so, my answer changes to =E2=80=9CNO=E2=80=9D.<br><b=
r>=C2=A0 =C2=A0=20
    =C2=A0 =C2=A0 paul<br>
    <div>
    <div><br>_______________________________________________<br>IPsec=20
    mailing list<br><a href=3D"mailto:IPsec@ietf.org" target=3D"_blank">IPs=
ec@ietf.org</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/ipsec" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/ipsec</a><br></div>=
</div></blockquote></div><br></div>
  </span><p>
  </p><hr><span class=3D"">

  <p></p>_______________________________________________<br>IPsec mailing=
=20
  list<br><a href=3D"mailto:IPsec@ietf.org" target=3D"_blank">IPsec@ietf.or=
g</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/ipsec" target=3D"=
_blank">https://www.ietf.org/mailman/listinfo/ipsec</a><br></span><p></p></=
blockquote></div>
</blockquote></div><br></div>

--001a11c266d8c2098f0502c23be8--


From nobody Wed Sep 10 22:35:11 2014
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067CB1A0464 for <ipsec@ietfa.amsl.com>; Wed, 10 Sep 2014 22:35:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kVzlmG2Pu_i for <ipsec@ietfa.amsl.com>; Wed, 10 Sep 2014 22:35:07 -0700 (PDT)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE50A1A0459 for <ipsec@ietf.org>; Wed, 10 Sep 2014 22:35:06 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id x12so6131832wgg.26 for <ipsec@ietf.org>; Wed, 10 Sep 2014 22:35:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=WrwuiZvfYIh7f6ffNvlBAVqQ1KkDja6bcNP14gCp7Yk=; b=umUWGtS8Cd+H3YFWx+gnhkIfMxQIJZXYVPsdGoWOU+9dXDCO+AiOHos9Uq8kn1tx8t RuHG8GhUFL9/40BlO64ysLBNl8IFOx3DkSFlPM9YcoxM3ohyJxFevG8LuAhwABUAU/nT YU4O8S4y6iDeyhCZZogE4cDxA+kDTmYLfKRhVHGWO+m0wwg5l495UkEUCzEF8knOkysX +x4wLGad0eVjmGkU+YBNlFsdu607O2Zh6acs3fZ45Gs/3l7Wc5QvWIqyNw4RDXsWt0wN kG8YLIa1CNxAs/J0zSRialibUrCpe97NJOLpR/jBekU5Vu32Wawd+4wypG/l79KnrEIZ nkYA==
X-Received: by 10.180.93.5 with SMTP id cq5mr4394245wib.16.1410413705325; Wed, 10 Sep 2014 22:35:05 -0700 (PDT)
Received: from [10.0.0.9] (bzq-79-177-135-86.red.bezeqint.net. [79.177.135.86]) by mx.google.com with ESMTPSA id bt9sm20839565wjc.44.2014.09.10.22.35.04 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Sep 2014 22:35:04 -0700 (PDT)
Message-ID: <54113486.9020601@gmail.com>
Date: Thu, 11 Sep 2014 08:35:02 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Rahul Vaidya <rahul.stds@gmail.com>, ipsec@ietf.org
References: <CAEX11nYFEj-f8m-8fK-j7FH-EDavG0XgmJwonFMj_V_5eJHFzQ@mail.gmail.com>
In-Reply-To: <CAEX11nYFEj-f8m-8fK-j7FH-EDavG0XgmJwonFMj_V_5eJHFzQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/xRwmasJUsLMR8J8rrSht7P9Pgqc
Subject: Re: [IPsec] Mandatory Public Key based authentication with EAP
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Sep 2014 05:35:09 -0000

Hi Rahul,

This is why RFC 5998 is listed as "updates 5996". So RFC 5998 does apply 
here. Note that it only applies in specific cases, and for specific EAP 
methods.

Yes, we should have updated the text in RFC 5996 to refer to 5998, but 
we forgot. Sigh.

Thanks,
	Yaron

On 09/11/2014 06:56 AM, Rahul Vaidya wrote:
> Dear IPsec Experts,
>
> In RFC 4306, 5996 as well as draft-kivinen-ipsecme-ikev2-rfc5996bis,
> there is a statement:
>
> "An implementation using EAP MUST also use a public-key-based
> authentication of the server to the client before the EAP exchange
> begins, even if the EAP method offers mutual authentication."
>
> RFC 5998 which updates 5996 says:
> "This document specifies how EAP methods that provide mutual
> authentication and key agreement can be used to provide extensible
> responder authentication for IKEv2 based on methods other than public
> key signatures."
>
> The 2 statements are contradictory, given the 'MUST' requirement for
> public -key based authentication in RFC 5996.
>
> I request a view from the IPsec community on whether public key based
> authentication can be avoided without impacting the security of the
> connection/network.
>
> Regards,
> Rahul Vaidya
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


From nobody Wed Sep 10 22:44:16 2014
Return-Path: <rahul.stds@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C80A1A03BF for <ipsec@ietfa.amsl.com>; Wed, 10 Sep 2014 22:44:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpqOkKh_OZiE for <ipsec@ietfa.amsl.com>; Wed, 10 Sep 2014 22:44:12 -0700 (PDT)
Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65BB1A0464 for <ipsec@ietf.org>; Wed, 10 Sep 2014 22:44:12 -0700 (PDT)
Received: by mail-pa0-f53.google.com with SMTP id rd3so8349013pab.26 for <ipsec@ietf.org>; Wed, 10 Sep 2014 22:44:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vAVqRANYM+1Geg+Hw4+5lP7vMU1hGoIEyd8lzWLacCI=; b=AMeZPjPhBha5FIeKBi2GGEpTLkTRvZKqs3lwqMrQfB4u08o4345b2l+Ksj72uA1iUr a93G1tDrAbj5jDiJCPtLHFpt+CdFbypp5QT54/hjVxyQtmHigY4S7iTmrwoYrZeMSEy6 mMeuQFUXZcZ4EIJI6tbiz+Y+cQKgBo25BJTy/FIRWVyHgtpcusRxSMoJcOJmKKrByboD D3UI3TFxHHpGZECnJjL7lDEguyq4f3uQcxoBFPITkGp+Hhz5czfaQQH2OgtoWmrNqLYk xcxUUkY2wEe1qiJOjHJAPpJv10MAgVB0SMRgyTloRpO01/p1pMAp8CBi7zmjDmJRWQMv xARA==
MIME-Version: 1.0
X-Received: by 10.67.15.71 with SMTP id fm7mr70226437pad.45.1410414252521; Wed, 10 Sep 2014 22:44:12 -0700 (PDT)
Received: by 10.70.82.101 with HTTP; Wed, 10 Sep 2014 22:44:12 -0700 (PDT)
In-Reply-To: <54113486.9020601@gmail.com>
References: <CAEX11nYFEj-f8m-8fK-j7FH-EDavG0XgmJwonFMj_V_5eJHFzQ@mail.gmail.com> <54113486.9020601@gmail.com>
Date: Thu, 11 Sep 2014 11:14:12 +0530
Message-ID: <CAEX11nbgia1scyZQjU9VxGiqZPC2bv7rUd6i9BR0U5tF2vZ9Yw@mail.gmail.com>
From: Rahul Vaidya <rahul.stds@gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=001a11344dac81ff370502c3a8ec
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/oVAfXuciPWEOh8IDAraWVL0x_Ds
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Mandatory Public Key based authentication with EAP
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Sep 2014 05:44:14 -0000

--001a11344dac81ff370502c3a8ec
Content-Type: text/plain; charset=UTF-8

Thanks for the quick reply, Yaron,

So does it mean that if an EAP method provides mutual authentication (e.g.,
EAP-AKA), then this particular text from 5996 does not apply? Or are their
further conditions which are not mentioned in 5998 where still the public
key based authentication is required?

Regards,
Rahul

On Thu, Sep 11, 2014 at 11:05 AM, Yaron Sheffer <yaronf.ietf@gmail.com>
wrote:

> Hi Rahul,
>
> This is why RFC 5998 is listed as "updates 5996". So RFC 5998 does apply
> here. Note that it only applies in specific cases, and for specific EAP
> methods.
>
> Yes, we should have updated the text in RFC 5996 to refer to 5998, but we
> forgot. Sigh.
>
> Thanks,
>         Yaron
>
>
> On 09/11/2014 06:56 AM, Rahul Vaidya wrote:
>
>> Dear IPsec Experts,
>>
>> In RFC 4306, 5996 as well as draft-kivinen-ipsecme-ikev2-rfc5996bis,
>> there is a statement:
>>
>> "An implementation using EAP MUST also use a public-key-based
>> authentication of the server to the client before the EAP exchange
>> begins, even if the EAP method offers mutual authentication."
>>
>> RFC 5998 which updates 5996 says:
>> "This document specifies how EAP methods that provide mutual
>> authentication and key agreement can be used to provide extensible
>> responder authentication for IKEv2 based on methods other than public
>> key signatures."
>>
>> The 2 statements are contradictory, given the 'MUST' requirement for
>> public -key based authentication in RFC 5996.
>>
>> I request a view from the IPsec community on whether public key based
>> authentication can be avoided without impacting the security of the
>> connection/network.
>>
>> Regards,
>> Rahul Vaidya
>>
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>>

--001a11344dac81ff370502c3a8ec
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks for the quick reply, Yaron,<div><br></div><div>So d=
oes it mean that if an EAP method provides mutual authentication (e.g., EAP=
-AKA), then this particular text from 5996 does not apply? Or are their fur=
ther conditions which are not mentioned in 5998 where still the public key =
based authentication is required?</div><div><br></div><div>Regards,</div><d=
iv>Rahul</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e">On Thu, Sep 11, 2014 at 11:05 AM, Yaron Sheffer <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:yaronf.ietf@gmail.com" target=3D"_blank">yaronf.ietf@gmail.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Rahul,<br>
<br>
This is why RFC 5998 is listed as &quot;updates 5996&quot;. So RFC 5998 doe=
s apply here. Note that it only applies in specific cases, and for specific=
 EAP methods.<br>
<br>
Yes, we should have updated the text in RFC 5996 to refer to 5998, but we f=
orgot. Sigh.<br>
<br>
Thanks,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron<div><div class=3D"h5"><br>
<br>
On 09/11/2014 06:56 AM, Rahul Vaidya wrote:<br>
</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5">
Dear IPsec Experts,<br>
<br>
In RFC 4306, 5996 as well as draft-kivinen-ipsecme-ikev2-<u></u>rfc5996bis,=
<br>
there is a statement:<br>
<br>
&quot;An implementation using EAP MUST also use a public-key-based<br>
authentication of the server to the client before the EAP exchange<br>
begins, even if the EAP method offers mutual authentication.&quot;<br>
<br>
RFC 5998 which updates 5996 says:<br>
&quot;This document specifies how EAP methods that provide mutual<br>
authentication and key agreement can be used to provide extensible<br>
responder authentication for IKEv2 based on methods other than public<br>
key signatures.&quot;<br>
<br>
The 2 statements are contradictory, given the &#39;MUST&#39; requirement fo=
r<br>
public -key based authentication in RFC 5996.<br>
<br>
I request a view from the IPsec community on whether public key based<br>
authentication can be avoided without impacting the security of the<br>
connection/network.<br>
<br>
Regards,<br>
Rahul Vaidya<br>
<br>
<br></div></div>
______________________________<u></u>_________________<br>
IPsec mailing list<br>
<a href=3D"mailto:IPsec@ietf.org" target=3D"_blank">IPsec@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/ipsec" target=3D"_blank">h=
ttps://www.ietf.org/mailman/<u></u>listinfo/ipsec</a><br>
<br>
</blockquote>
</blockquote></div><br></div>

--001a11344dac81ff370502c3a8ec--


From nobody Wed Sep 10 22:59:12 2014
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC9D1A046C for <ipsec@ietfa.amsl.com>; Wed, 10 Sep 2014 22:59:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YI_4Jmn6_ZbS for <ipsec@ietfa.amsl.com>; Wed, 10 Sep 2014 22:59:10 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9EA41A0464 for <ipsec@ietf.org>; Wed, 10 Sep 2014 22:59:09 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id q5so318429wiv.5 for <ipsec@ietf.org>; Wed, 10 Sep 2014 22:59:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=auFjItH7x0sZBdGnMprgDabEfR0rzOoT02DaQwqFpZU=; b=wSaIHdYpfxw9UsL9tm8uYJSVWHAb7uMbxSP9H4rUrKmW371UPVc+vD0oczWb6rQAdX /gfFBuuypHLrWPr6/JWmOkaaUn6ebPMkuZM1TSo4P+7KglEfmz4WwgV+cfPOkNxKGXYb bD4VgNTA7RGkEzk8YIeC6Rub2wUi/fEKETYMJ0oFfgqSBnXMbVTjQvV2dPj88KyiDzRw S7R/rTS4IFtILAJT/aVwoW5In1coKAbPKB1QNsoE3OQMAlmVy8g8HY4Ftv6OjHICkhYO KZNb7rLk49ClPLD0aBwUbkH14j+u9DLqwbPQHtMna8w2GAbyoNmVY5x/9sL+et2cL3Sd +2Ug==
X-Received: by 10.194.60.240 with SMTP id k16mr523639wjr.109.1410415148305; Wed, 10 Sep 2014 22:59:08 -0700 (PDT)
Received: from [10.0.0.4] (bzq-79-177-0-22.red.bezeqint.net. [79.177.0.22]) by mx.google.com with ESMTPSA id a5sm20914944wje.17.2014.09.10.22.59.07 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Sep 2014 22:59:07 -0700 (PDT)
Message-ID: <54113A28.6060305@gmail.com>
Date: Thu, 11 Sep 2014 08:59:04 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Rahul Vaidya <rahul.stds@gmail.com>
References: <CAEX11nYFEj-f8m-8fK-j7FH-EDavG0XgmJwonFMj_V_5eJHFzQ@mail.gmail.com>	<54113486.9020601@gmail.com> <CAEX11nbgia1scyZQjU9VxGiqZPC2bv7rUd6i9BR0U5tF2vZ9Yw@mail.gmail.com>
In-Reply-To: <CAEX11nbgia1scyZQjU9VxGiqZPC2bv7rUd6i9BR0U5tF2vZ9Yw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/RPP3d-0LGipqlY24qo4r3ksoORE
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Mandatory Public Key based authentication with EAP
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Sep 2014 05:59:11 -0000

Hi Rahul,

I am not aware of any additional conditions.

EAP-AKA is actually listed in the table in RFC 5998, Sec. 4.

Thanks,
	Yaron

On 09/11/2014 08:44 AM, Rahul Vaidya wrote:
> Thanks for the quick reply, Yaron,
>
> So does it mean that if an EAP method provides mutual authentication
> (e.g., EAP-AKA), then this particular text from 5996 does not apply? Or
> are their further conditions which are not mentioned in 5998 where still
> the public key based authentication is required?
>
> Regards,
> Rahul
>
> On Thu, Sep 11, 2014 at 11:05 AM, Yaron Sheffer <yaronf.ietf@gmail.com
> <mailto:yaronf.ietf@gmail.com>> wrote:
>
>     Hi Rahul,
>
>     This is why RFC 5998 is listed as "updates 5996". So RFC 5998 does
>     apply here. Note that it only applies in specific cases, and for
>     specific EAP methods.
>
>     Yes, we should have updated the text in RFC 5996 to refer to 5998,
>     but we forgot. Sigh.
>
>     Thanks,
>              Yaron
>
>
>     On 09/11/2014 06:56 AM, Rahul Vaidya wrote:
>
>         Dear IPsec Experts,
>
>         In RFC 4306, 5996 as well as
>         draft-kivinen-ipsecme-ikev2-__rfc5996bis,
>         there is a statement:
>
>         "An implementation using EAP MUST also use a public-key-based
>         authentication of the server to the client before the EAP exchange
>         begins, even if the EAP method offers mutual authentication."
>
>         RFC 5998 which updates 5996 says:
>         "This document specifies how EAP methods that provide mutual
>         authentication and key agreement can be used to provide extensible
>         responder authentication for IKEv2 based on methods other than
>         public
>         key signatures."
>
>         The 2 statements are contradictory, given the 'MUST' requirement for
>         public -key based authentication in RFC 5996.
>
>         I request a view from the IPsec community on whether public key
>         based
>         authentication can be avoided without impacting the security of the
>         connection/network.
>
>         Regards,
>         Rahul Vaidya
>
>
>         _________________________________________________
>         IPsec mailing list
>         IPsec@ietf.org <mailto:IPsec@ietf.org>
>         https://www.ietf.org/mailman/__listinfo/ipsec
>         <https://www.ietf.org/mailman/listinfo/ipsec>
>
>


From nobody Wed Sep 10 23:15:03 2014
Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7F01A0479 for <ipsec@ietfa.amsl.com>; Wed, 10 Sep 2014 23:15:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkVOcHcrVugE for <ipsec@ietfa.amsl.com>; Wed, 10 Sep 2014 23:14:59 -0700 (PDT)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D3441A048E for <ipsec@ietf.org>; Wed, 10 Sep 2014 23:14:59 -0700 (PDT)
Received: by mail-lb0-f169.google.com with SMTP id p9so11123063lbv.14 for <ipsec@ietf.org>; Wed, 10 Sep 2014 23:14:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=8sUO/3EqHm1vxP/+g/cn73pfH/Dwsmc6pQd+8y0k+4E=; b=wlpVXAOoe0/X29NAHr0f9EmLPAJKipIz75OctnATW0+XKmRAYPPPY2bcT3uWnQ4yW0 FQpH31uGJF/MxaADEGRHndZgUMfADycnRkJvcsPGioltETXDsJ1fMM/TsWRQjVvHE+Eb PG4CBahIpEYzQq2vLJAInEWXTTGtXVGxiNuj3Fi6OQH/X3CEslLM6T5AG4bbrnhRWyX2 mfE4dcx29G9kecpIvLVzu3y0eZ/o98pXDlHFyOF5L7/JJXKielgJoXUyz+8aQ+OM1Pau 8jv37u4203gFHwL7Ye66J1kqwNaNioswsPqjfQMvUs72i9RgcMR7HyUPwP88Y1uvJHbp Ys4g==
X-Received: by 10.112.61.68 with SMTP id n4mr1075041lbr.91.1410416097560; Wed, 10 Sep 2014 23:14:57 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id pr7sm3430080lbc.18.2014.09.10.23.14.56 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 10 Sep 2014 23:14:56 -0700 (PDT)
Message-ID: <6ECDED003BD7418EAD5D555A64F80A68@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Yaron Sheffer" <yaronf.ietf@gmail.com>, "Rahul Vaidya" <rahul.stds@gmail.com>
References: <CAEX11nYFEj-f8m-8fK-j7FH-EDavG0XgmJwonFMj_V_5eJHFzQ@mail.gmail.com>	<54113486.9020601@gmail.com> <CAEX11nbgia1scyZQjU9VxGiqZPC2bv7rUd6i9BR0U5tF2vZ9Yw@mail.gmail.com> <54113A28.6060305@gmail.com>
Date: Thu, 11 Sep 2014 10:15:26 +0400
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/g0uc-7HHwTbMNWCwN3TEprnSCPg
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Mandatory Public Key based authentication with EAP
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Sep 2014 06:15:01 -0000

Hi Rahul, Yaron,

> Hi Rahul,
>
> I am not aware of any additional conditions.

Sorry to pop up, but doesn't text from RFC5998 apply only
to EAP-only authentication? Isn't it an additional condition?

I mean, that if you perform EAP authentication, as described
in RFC5996, i.e. when responder does send AUTH payload
in its first reply to IKE_AUTH, then even if you use
EAP method with mutual authentiaction, the responder
must use public signature to compute this AUTH payload.

So, from my reading, RFC5998 updates RFC5996 in the sense,
that responder is not needed to send this AUTH payload
(and therefore, to use PK signature to compute it)
if (and only if) it receives EAP_ONLY_AUTHENTICATION and honors it.

Regards,
Valery.

> EAP-AKA is actually listed in the table in RFC 5998, Sec. 4.
>
> Thanks,
> Yaron
>
> On 09/11/2014 08:44 AM, Rahul Vaidya wrote:
>> Thanks for the quick reply, Yaron,
>>
>> So does it mean that if an EAP method provides mutual authentication
>> (e.g., EAP-AKA), then this particular text from 5996 does not apply? Or
>> are their further conditions which are not mentioned in 5998 where still
>> the public key based authentication is required?
>>
>> Regards,
>> Rahul
>>
>> On Thu, Sep 11, 2014 at 11:05 AM, Yaron Sheffer <yaronf.ietf@gmail.com
>> <mailto:yaronf.ietf@gmail.com>> wrote:
>>
>>     Hi Rahul,
>>
>>     This is why RFC 5998 is listed as "updates 5996". So RFC 5998 does
>>     apply here. Note that it only applies in specific cases, and for
>>     specific EAP methods.
>>
>>     Yes, we should have updated the text in RFC 5996 to refer to 5998,
>>     but we forgot. Sigh.
>>
>>     Thanks,
>>              Yaron
>>
>>
>>     On 09/11/2014 06:56 AM, Rahul Vaidya wrote:
>>
>>         Dear IPsec Experts,
>>
>>         In RFC 4306, 5996 as well as
>>         draft-kivinen-ipsecme-ikev2-__rfc5996bis,
>>         there is a statement:
>>
>>         "An implementation using EAP MUST also use a public-key-based
>>         authentication of the server to the client before the EAP 
>> exchange
>>         begins, even if the EAP method offers mutual authentication."
>>
>>         RFC 5998 which updates 5996 says:
>>         "This document specifies how EAP methods that provide mutual
>>         authentication and key agreement can be used to provide 
>> extensible
>>         responder authentication for IKEv2 based on methods other than
>>         public
>>         key signatures."
>>
>>         The 2 statements are contradictory, given the 'MUST' requirement 
>> for
>>         public -key based authentication in RFC 5996.
>>
>>         I request a view from the IPsec community on whether public key
>>         based
>>         authentication can be avoided without impacting the security of 
>> the
>>         connection/network.
>>
>>         Regards,
>>         Rahul Vaidya
>>
>>
>>         _________________________________________________
>>         IPsec mailing list
>>         IPsec@ietf.org <mailto:IPsec@ietf.org>
>>         https://www.ietf.org/mailman/__listinfo/ipsec
>>         <https://www.ietf.org/mailman/listinfo/ipsec>
>>
>>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec 


From nobody Wed Sep 10 23:19:24 2014
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC171A04AA for <ipsec@ietfa.amsl.com>; Wed, 10 Sep 2014 23:19:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnHnFL86Omwa for <ipsec@ietfa.amsl.com>; Wed, 10 Sep 2014 23:19:20 -0700 (PDT)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87F201A01FF for <ipsec@ietf.org>; Wed, 10 Sep 2014 23:19:20 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id y10so5037852wgg.3 for <ipsec@ietf.org>; Wed, 10 Sep 2014 23:19:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jMa/EQ2th6sNIJucUzcLalu2maJslc/3HGOavprJy3k=; b=qvY3A5SaaXViSiWG0unqbhjPRWrtYMLmx2yMkdCson2QkVjdyj7QjskiD6wd28Xk57 vEjh78hNMhPhJEOLvgDw4sfvMkuennTCuTPqqetaxAh19dPzfl6cwJ307kQbmDPlnWQR yL9e+UgEZr+10fe4LwvDCOEymUVOgPG8c5xR7m/rqM+qPXiF4eDTVanmIKBW9/VHT0MQ R5DfbSPeAc1HBuuLDk/BJGhZ+0KOSWWfM10Dne7LmcM5iFxHYyQ8P2Kf4CMwsmP1wqFo IyWAgup0JXcGnMkK106O4G3YaQpdILo3MXLj5B0HWhlxNUZR5TVyVnQ1adAIehTcFBw2 v2eA==
X-Received: by 10.194.94.73 with SMTP id da9mr33283923wjb.67.1410416359040; Wed, 10 Sep 2014 23:19:19 -0700 (PDT)
Received: from [10.0.0.4] (bzq-79-177-0-22.red.bezeqint.net. [79.177.0.22]) by mx.google.com with ESMTPSA id i6sm4777475wib.7.2014.09.10.23.19.18 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Sep 2014 23:19:18 -0700 (PDT)
Message-ID: <54113EE3.6040402@gmail.com>
Date: Thu, 11 Sep 2014 09:19:15 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Valery Smyslov <svanru@gmail.com>,  Rahul Vaidya <rahul.stds@gmail.com>
References: <CAEX11nYFEj-f8m-8fK-j7FH-EDavG0XgmJwonFMj_V_5eJHFzQ@mail.gmail.com>	<54113486.9020601@gmail.com> <CAEX11nbgia1scyZQjU9VxGiqZPC2bv7rUd6i9BR0U5tF2vZ9Yw@mail.gmail.com> <54113A28.6060305@gmail.com> <6ECDED003BD7418EAD5D555A64F80A68@buildpc>
In-Reply-To: <6ECDED003BD7418EAD5D555A64F80A68@buildpc>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/shplWR-sSCZfTl7zxsNBrF6W7Oo
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Mandatory Public Key based authentication with EAP
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Sep 2014 06:19:22 -0000

Hi Valery,

Thanks for popping up :-)

You are right of course. The EAP_ONLY_AUTHENTICATION notification is 
mandatory in this case. I just didn't think of it as an additional 
condition.

Best,
	Yaron

On 09/11/2014 09:15 AM, Valery Smyslov wrote:
> Hi Rahul, Yaron,
>
>> Hi Rahul,
>>
>> I am not aware of any additional conditions.
>
> Sorry to pop up, but doesn't text from RFC5998 apply only
> to EAP-only authentication? Isn't it an additional condition?
>
> I mean, that if you perform EAP authentication, as described
> in RFC5996, i.e. when responder does send AUTH payload
> in its first reply to IKE_AUTH, then even if you use
> EAP method with mutual authentiaction, the responder
> must use public signature to compute this AUTH payload.
>
> So, from my reading, RFC5998 updates RFC5996 in the sense,
> that responder is not needed to send this AUTH payload
> (and therefore, to use PK signature to compute it)
> if (and only if) it receives EAP_ONLY_AUTHENTICATION and honors it.
>
> Regards,
> Valery.
>
>> EAP-AKA is actually listed in the table in RFC 5998, Sec. 4.
>>
>> Thanks,
>> Yaron
>>
>> On 09/11/2014 08:44 AM, Rahul Vaidya wrote:
>>> Thanks for the quick reply, Yaron,
>>>
>>> So does it mean that if an EAP method provides mutual authentication
>>> (e.g., EAP-AKA), then this particular text from 5996 does not apply? Or
>>> are their further conditions which are not mentioned in 5998 where still
>>> the public key based authentication is required?
>>>
>>> Regards,
>>> Rahul
>>>
>>> On Thu, Sep 11, 2014 at 11:05 AM, Yaron Sheffer <yaronf.ietf@gmail.com
>>> <mailto:yaronf.ietf@gmail.com>> wrote:
>>>
>>>     Hi Rahul,
>>>
>>>     This is why RFC 5998 is listed as "updates 5996". So RFC 5998 does
>>>     apply here. Note that it only applies in specific cases, and for
>>>     specific EAP methods.
>>>
>>>     Yes, we should have updated the text in RFC 5996 to refer to 5998,
>>>     but we forgot. Sigh.
>>>
>>>     Thanks,
>>>              Yaron
>>>
>>>
>>>     On 09/11/2014 06:56 AM, Rahul Vaidya wrote:
>>>
>>>         Dear IPsec Experts,
>>>
>>>         In RFC 4306, 5996 as well as
>>>         draft-kivinen-ipsecme-ikev2-__rfc5996bis,
>>>         there is a statement:
>>>
>>>         "An implementation using EAP MUST also use a public-key-based
>>>         authentication of the server to the client before the EAP
>>> exchange
>>>         begins, even if the EAP method offers mutual authentication."
>>>
>>>         RFC 5998 which updates 5996 says:
>>>         "This document specifies how EAP methods that provide mutual
>>>         authentication and key agreement can be used to provide
>>> extensible
>>>         responder authentication for IKEv2 based on methods other than
>>>         public
>>>         key signatures."
>>>
>>>         The 2 statements are contradictory, given the 'MUST'
>>> requirement for
>>>         public -key based authentication in RFC 5996.
>>>
>>>         I request a view from the IPsec community on whether public key
>>>         based
>>>         authentication can be avoided without impacting the security
>>> of the
>>>         connection/network.
>>>
>>>         Regards,
>>>         Rahul Vaidya
>>>
>>>
>>>         _________________________________________________
>>>         IPsec mailing list
>>>         IPsec@ietf.org <mailto:IPsec@ietf.org>
>>>         https://www.ietf.org/mailman/__listinfo/ipsec
>>>         <https://www.ietf.org/mailman/listinfo/ipsec>
>>>
>>>
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>


From nobody Thu Sep 11 00:24:05 2014
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1AB1A03E2 for <ipsec@ietfa.amsl.com>; Thu, 11 Sep 2014 00:24:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADo7eGyI8ZMK for <ipsec@ietfa.amsl.com>; Thu, 11 Sep 2014 00:24:03 -0700 (PDT)
Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A19DB1A058E for <ipsec@ietf.org>; Thu, 11 Sep 2014 00:24:02 -0700 (PDT)
Received: by mail-we0-f182.google.com with SMTP id k48so4037313wev.41 for <ipsec@ietf.org>; Thu, 11 Sep 2014 00:24:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BxuR/+bxMGOL6BQyDmP5sb0BMnlKZCtnnJ2gkIq2yCc=; b=qSvKZ6bLJtgr/FXN4sDcbo7WSu8rBiQUSW0jQI8nORKbGvNtTF/9qZOMFePaAQqP04 clLHwdebw9OtjWcy51RD0sjwg+vNwnBAeafcXiv9+Hpg/v2UIbb8PFmcwsDuai7QeDeh yZm2W0H8GsxpuL/zZeOr6Afx7ADSbOffd7R9k4UU8Mxx+ADo/K4bnlRrDafZc/yMcLDy edjgnOtAQ6rCkFy0feg3woUUXK94zwmXevOQadxoQrjyAqmg+ULeN6agbr6dOcxyj3bx oXbBvF5AEeO4dNDixWV3ktnwf7UHdEdoE0YYa4fbjvdk/iIYqes6XZjyjve2OamBq40T lrBg==
X-Received: by 10.180.198.232 with SMTP id jf8mr4583614wic.37.1410420241305; Thu, 11 Sep 2014 00:24:01 -0700 (PDT)
Received: from [10.2.0.78] (85-250-123-108.bb.netvision.net.il. [85.250.123.108]) by mx.google.com with ESMTPSA id a5sm178131wje.17.2014.09.11.00.24.00 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Sep 2014 00:24:00 -0700 (PDT)
Message-ID: <54114E0E.80108@gmail.com>
Date: Thu, 11 Sep 2014 10:23:58 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Hugo Krawczyk <hugo@ee.technion.ac.il>, Valery Smyslov <svanru@gmail.com>
References: <540CA9B2.3090807@gmail.com> <BE175F90-68B6-4731-B32E-BA9EF3F3BAD8@dell.com> <CADi0yUM3ESC9A1WaJJZ5QKrAeUd-wiNLFRdpRUYp5vGXir-A6Q@mail.gmail.com> <6E9345DD1E9A43158A0DD61F96C09741@buildpc> <CADi0yUMQftcsij+aH5XB2O97LZ7fVJeq2jNTHqK5kvsaZuSWYQ@mail.gmail.com>
In-Reply-To: <CADi0yUMQftcsij+aH5XB2O97LZ7fVJeq2jNTHqK5kvsaZuSWYQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/EabSkyEYs4ue0wblpK6j6mFaF7s
Cc: IPsecme WG <ipsec@ietf.org>, Paul_Koning@dell.com
Subject: Re: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Sep 2014 07:24:04 -0000

Hi Hugo,

We know what to expect from IKEv2 with mutual certificate or PSK 
authentication.

I *think* we also know what IKEv2 provides when both sides are NOT 
authenticated. To summarize my own understanding: the IKE exchange and 
any resulting Child SAs are confidential (only encrypted payloads of 
course) and integrity protected, provided there was no MITM attacker at 
the time of the initial IKE exchange. If there was one, all bets are off.

The document is unclear about the security properties of the proposed 
1-way auth, but from the discussion, many people believe it is similar 
to TLS. I agree that a serious analysis of this option is called for.

The document's introduction does give the impression that the main point 
of this document is one-way auth, but I think most of the people who 
support this document are more interested in fully anonymous key 
exchange. So I would like to focus the WG adoption discussion right now 
on the anonymous use case, and then, if the WG decides to adopt the 
document, go back to the question you raised.

Thanks,
	Yaron

On 09/11/2014 07:01 AM, Hugo Krawczyk wrote:
> I didn't know (or remember) that IKEv2 allows for different directional
> authentication mechanisms.
> In any case, as a general rule, the fact that two methods are secure,
> doesn't mean that mix-and-match-ing them (or taking a subset) is still
> secure.
> Particularly for IKEv2, I do not know of any work that has shown such
> security.
>
> Hugo
>
> On Tue, Sep 9, 2014 at 7:58 AM, Valery Smyslov <svanru@gmail.com
> <mailto:svanru@gmail.com>> wrote:
>
>     __
>     Hi Hugo,
>
>         The subject line (and the comment on Bellovin attack) caught my
>         eye. I don't follow the discussions in this list so I don't know
>         how much the need and dangers of unauthenticated methods were
>         discussed here. I want to point out that (and probably many did
>         before me) that un-authentication is a very tricky option
>         especially in a protocol that was created with mutual
>         authentication as a core requirement and assumption. I can see
>         potential benefits and uses but I can also see it abused and
>         misused (the internet draft doesn't do too good a job warning
>         about it but even if it did, people will misuse it).
>
>     I agree that the draft's Security Consideration section in its
>     current form is incomplete.
>     And I hope that if the draft is adopted then it will draw an
>     attention of many people,
>     who will help to improve the Security Considerations to list all the
>     caveats,
>     to make all possible warning and to give advice how to safely use
>     this mode.
>
>         But requirements aside, I cannot vow for the security of IKE's
>         key exchange in a one-way authentication mode. No one (that I
>         know, definitely not me) designed this protocol to support
>         one-way authentication. So the question of whether it is secure
>         in this setting has not been investigated. Moreover, I see that
>         the draft uses shared-key fields for theanonymous side of the
>         communication and, I imagine, the other can use signature-based
>         authentication. What security properties do you get from that
>         mix-and-match authentication methods?
>
>     IKEv2 currently allows the peers to use different authentication
>     methods.
>     So, if one of the peers uses preshared key, while the other uses
>     digital signature, then it is considered legal and secure from
>     protocol's design point of view. If the peer, using preshared key in
>     this scenario,
>     uses key, known to everyone, then we will get one-way authentication
>     with the current IKEv2. The next step, that the draft does - get rid of
>     well-known preshared key and compute the content of the AUTH Payload
>     the same way it is computed currently in IKEv2 when it is used
>     with non key generating EAP methods - using SK_pi (or SK_Pr) as the key
>     I believe the draft doesn't change the way cryptography is used in
>     IKEv2.
>
>         One likely misuse of this technique is that people will use
>         unauthenticated (or one-way) IKE and will run some other
>         authentication on top of it (say, password based or whatever).
>         Well, protocols do not necessarily compose securely. TLS had
>         many failures like that (BEAST, re-negotiation, triple
>         handshake, ...) and IPsec saw examples of that in the
>         combinations of unauthenticated ESP and AH. IKE's cryptographic
>         design has endured the test of time but these variations (or
>         improvisations) endanger it.
>
>     Well, sometimes mutual authentication is impossible or undesirable.
>     Sometimes privacy is more important and people are ready to
>     sacrifice some level of security to keep their privacy.
>     And sometimes the choice is - either use plaintext
>     or unauthenticated encryption. The latter at least
>     prevents passive eavesdropping...
>
>         Finally, since Bellovin's attack was mentioned, I want to make
>         sure that no one is thinking of not using the MAC authentication
>         at the IP packet level, right?
>
>     Absolutely.
>
>         Hugo
>
>     Regards,
>     Valery Smyslov.
>
>         On Mon, Sep 8, 2014 at 10:54 AM, <Paul_Koning@dell.com
>         <mailto:Paul_Koning@dell.com>> wrote:
>
>
>             On Sep 7, 2014, at 2:53 PM, Yaron Sheffer
>             <yaronf.ietf@gmail.com <mailto:yaronf.ietf@gmail.com>> wrote:
>
>             > Dear working group,
>             >
>             > This is a call foradopting draft-smyslov-ipsecme-ikev2-null-auth as a WG
>             document. Please respond to this mail with a Yes or No and a
>             short rationale, at latest by Friday Sep. 12.
>
>             Maybe.
>
>             I understand and support the rationale for this draft.
>
>             The Security Considerations seems to be inadequate.
>             Whenever possible, real authentication should be used.  So
>             the Security Considerations should explicitly and strongly
>             emphasize that, and recommend that products that incorporate
>             Null authentication should strive to avoid its use whenever
>             possible, and steer users away from its use when they can.
>
>             A related question: does the use of Null authentication open
>             up the Bellovin attack?  It seems that it would.  If so, my
>             answer changes to “NO”.
>
>                  paul
>
>             _______________________________________________
>             IPsec mailing list
>             IPsec@ietf.org <mailto:IPsec@ietf.org>
>             https://www.ietf.org/mailman/listinfo/ipsec
>
>
>         ------------------------------------------------------------------------
>
>         _______________________________________________
>         IPsec mailing list
>         IPsec@ietf.org <mailto:IPsec@ietf.org>
>         https://www.ietf.org/mailman/listinfo/ipsec
>
>
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


From nobody Thu Sep 11 00:40:20 2014
Return-Path: <ivo.sedlacek@ericsson.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6EDF1A06C9 for <ipsec@ietfa.amsl.com>; Thu, 11 Sep 2014 00:40:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDgZgSy7j_ld for <ipsec@ietfa.amsl.com>; Thu, 11 Sep 2014 00:40:14 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2666C1A0601 for <ipsec@ietf.org>; Thu, 11 Sep 2014 00:40:12 -0700 (PDT)
X-AuditID: c1b4fb25-f791c6d00000617b-7d-541151db11c9
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 5C.53.24955.BD151145; Thu, 11 Sep 2014 09:40:11 +0200 (CEST)
Received: from ESESSMB301.ericsson.se ([169.254.1.77]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Thu, 11 Sep 2014 09:40:10 +0200
From: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>, "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: Review of draft-gundavelli-ipsecme-3gpp-ims-options-02
Thread-Index: AQHPzQ3SKMQYWriGR/e+ppRj0kUPVZv7jLDA
Date: Thu, 11 Sep 2014 07:40:09 +0000
Message-ID: <39B5E4D390E9BD4890E2B310790061011272F963@ESESSMB301.ericsson.se>
References: <39B5E4D390E9BD4890E2B310790061011272E731@ESESSMB301.ericsson.se> <D035BCAE.162A5C%sgundave@cisco.com>
In-Reply-To: <D035BCAE.162A5C%sgundave@cisco.com>
Accept-Language: en-US, cs-CZ
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B310790061011272F963ESESSMB301erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM+Jvje7tQMEQg3NfxS0WzVvAZLF/yws2 i/3rGpgsug5OZ7M4+GcbmwOrx6z7Z9k8pvzeyOqxc9Zddo8lS34yBbBEcdmkpOZklqUW6dsl cGVMmH+duWDHduaKE/9nsTUwfu5m7mLk5JAQMJHYuvc4lC0mceHeerYuRi4OIYGjjBKdayYw QziLGSUO329gBKliE9CTmLjlCCuILSIQKTFr3QWwDmaBfkaJK/ums4AkhAWcJeb/Wc0MUeQi MbnzChuEbSRx9tZ3sDiLgKpE98alQEM5OHgFfCVmzbMACQsJlEjsu/YVbBengKHE2a2zwFoZ BWQlrv7pBYszC4hL3HoynwniagGJJXvOQ30gKvHy8T9WkJESAooSy/vlIMrzJfo6rrKD2LwC ghInZz5hmcAoOgvJpFlIymYhKYOI60k8OzULytaWWLbwNTOErStx6eE6VmTxBYzsqxhFi1OL k3LTjYz1Uosyk4uL8/P08lJLNjECo/Tglt+qOxgvv3E8xCjAwajEw5tgJRgixJpYVlyZe4hR moNFSZx34bl5wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYVZZNlb6mKDFTT6eG7dvXsweY NxxgVt/0z/dG8k+HmJm5ZeV9k2bfO7DowXa3O0c7tx5suSolsMIk0b2h+G137cp01xnSbKH3 p3qk6L655vgmNjnZQavr8LYbv8tzZs857qcdVLGnX2sdp1OtwlPWeQ3t5wx2ad3cI3/3j+ai ro9LdLoU5nwPVGIpzkg01GIuKk4EAEYAUBuzAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/uW69c9kM3_5stP6S6nTaOYFeOVc
Cc: "Aeneas Dodd-Noble \(noblea\)" <noblea@cisco.com>, Jouni Korhonen <jouni.nospam@gmail.com>, "baboescu@broadcom.com" <baboescu@broadcom.com>
Subject: Re: [IPsec] Review of draft-gundavelli-ipsecme-3gpp-ims-options-02
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Sep 2014 07:40:19 -0000

--_000_39B5E4D390E9BD4890E2B310790061011272F963ESESSMB301erics_
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

Hello,

I checked draft-gundavelli-ipsecme-3gpp-ims-options-03.

My comments are resolved in draft-gundavelli-ipsecme-3gpp-ims-options-03

Thank you for taking my comments into account.

Kind regards

Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the b=
asis of the terms set out at www.ericsson.com/email_disclaimer<http://www.e=
ricsson.com/email_disclaimer>
From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: 10. z=E1=F8=ED 2014 17:42
To: Ivo Sedlacek; ipsec@ietf.org
Cc: Jouni Korhonen; Aeneas Dodd-Noble (noblea); baboescu@broadcom.com
Subject: Re: Review of draft-gundavelli-ipsecme-3gpp-ims-options-02

Hi Ivo,

Thanks for your response. Please see inline.


On 9/9/14 4:09 AM, "Ivo Sedlacek" <ivo.sedlacek@ericsson.com<mailto:ivo.sed=
lacek@ericsson.com>> wrote:

Hello,

I reviewed http://tools.ietf.org/id/draft-gundavelli-ipsecme-3gpp-ims-optio=
ns-02.txt and found the following issues:

ISSUE 1: the draft states:
------
These attributes can be
   used for carrying the IPv4 and IPv6 address of the Proxy-Call Control
   and Service function (P-CSCF).
------
In 3GPP, P-CSCF abbreviation stands for "Proxy-Call Session Control Functio=
n".

PROPOSAL 1: state:
------
These attributes can be
   used for carrying the IPv4 address and IPv6 address of the Proxy-Call Se=
ssion Control function (P-CSCF).
------


Ok




ISSUE 2: the draft states:
------
When an IPSec gateway delivers these
   attributes to an IPsec client, it can obtain the IPv4 and/or IPv6
   address of the P-CSCF server located in the home network.
------
The P-CSCF does not necessarily need to be located in the home network. In =
roaming situations, the P-CSCF can also be in visited network.
Example: User has a contract with an European operator. The user with its u=
ser equipment (UE) is in Japan and uses network of a Japanese operator. In =
such use case, the ePDG entity, the PGW entity and P-CSCF can all be in vis=
ited network (i.e. Japanese operator network).

PROPOSAL 2: state:
------
When an IPSec gateway delivers these
   attributes to an IPsec client, the IPsec client can obtain the IPv4 and/=
or IPv6
   address of the P-CSCF server located in the 3GPP network.
------

The "home" network terminology was not truly intended to reflect the 3GPP r=
oaming architecture. Its just to say the configuration comes from the PGW/L=
MA.

But, agree with the change.



ISSUE 3: the draft states:
------
   The Third Generation Partnership Project (3GPP) S2b reference point
   [TS23402], specified by the 3GPP system architecture defines a
   mechanism for allowing a mobile node (MN) attached in an untrusted
   non-3GPP IP Access Network to securely connect to the 3GPP home
   network and access IP services.
------
When roaming, the UE can access IP services in the 3GPP home network or 3GP=
P visited network. ePDG can be in visited or home network - see  http://www=
.3gpp.org/ftp/Specs/archive/23_series/23.402/23402-c50.zip section 4.5.4. I=
f so, P-GW and P-CSCF can also be in the visited network.

PROPOSAL 3: state:
------
   The Third Generation Partnership Project (3GPP) S2b reference point
   [TS23402], specified by the 3GPP system architecture defines a
   mechanism for allowing a mobile node (MN) attached in an untrusted
   non-3GPP IP Access Network to securely connect to a 3GPP
   network and access IP services.
------


The "home" network terminology was not truly intended to reflect the 3GPP r=
oaming architecture. Its just to say the configuration comes from the PGW/L=
MA.

But, agree with the change.




ISSUE 4: the draft states:
------
   A mobile node in this scenario may potentially need to access the IP
   Multimedia Subsystem (IMS) services in the home network.
------
P-CSCF can also be in visited network.

PROPOSAL 4: state:
------
   A mobile node in this scenario may potentially need to access the IP
   Multimedia Subsystem (IMS) services in the 3GPP network.
------



Ok




ISSUE 5: the draft states:
------
   Proxy-Call Session Control Function (P-CSCF)

      The P-CSCF is the entry point to the 3GPP IMS (IP Multimedia
      Subsystem) domain and serves as the outbound proxy server for the
      mobile node.  The mobile node attaches to the P-CSCF prior to
      performing IMS registrations and initiating SIP sessions.
------
Problems:
1) 3GPP IMS is not a domain.
2) The mobile node does NOT attach to P-CSCF prior to performing the IMS re=
gistration. Instead, the registration with IMS is the request for "attachme=
nt" to IMS.

PROPOSAL 5: state:
------
   Proxy-Call Session Control Function (P-CSCF)

      The P-CSCF is the entry point to the 3GPP IMS (IP Multimedia
      Subsystem)  and serves as the SIP outbound proxy for the
      mobile node.  The mobile node performs SIP registration to 3GPP IMS a=
nd initiates SIP sessions via a P-CSCF.
------


Thanks. That was a typo. It should have said, "the mobile node attaches to =
the 3GPP network ...".

Agree with the text.




ISSUE 6: the draft states:
------
Multiple P-CSCF
   servers MAY be requested by including a single instance of an empty
   P-CSCF_IP4_ADDRESS attribute with zero-length IPv4 Address field.
   The responder MAY respond with zero or more P-CSCF_IP4_ADDRESS
   attributes, and there is no implied order in the response.
------
IMO, the 1st sentence above is misleading as it suggests that the mobile no=
de has a choise to request one P-CSCF IPv4 address or to request multiple P=
-CSCF IPv4 addresses. However, in my reading of the rest of the draft, the =
mobile node has just one choise - request P-CSCF IPv4 addresses and receive=
 zero, one or several P-CSCF IPv4 addresses.

PROPOSAL 6: state:
------
If an instance of an empty
   P-CSCF_IP4_ADDRESS attribute with zero-length IPv4 Address field is incl=
uded by mobile node, the responder MAY respond with zero, one or more P-CSC=
F_IP4_ADDRESS
   attributes. If several P-CSCF_IP4_ADDRESS attributes are provided in one=
 IKEv2 message, there is no implied order among the P-CSCF_IP4_ADDRESS attr=
ibutes.
------


The proposed text is very clear. Thank you




ISSUE 7: the draft states:
------
Multiple P-CSCF
   servers MAY be requested by including a single instance of an empty
   P-CSCF_IP6_ADDRESS attribute with zero-length IPv6 Address field.
   The responder MAY respond with zero or more P-CSCF_IP6_ADDRESS
   attributes, and there is no implied order in the response.
------
IMO, the 1st sentence above is misleading as it suggests that the mobile no=
de has a choise to request one P-CSCF IPv6 address or to request multiple P=
-CSCF IPv6 addresses. However, in my reading of the rest of the draft, the =
mobile node has just one choise - request P-CSCF IPv6 addresses and receive=
 zero, one or several P-CSCF IPv6 addresses.

PROPOSAL 7: state:
------
If an instance of an empty
   P-CSCF_IP6_ADDRESS attribute with zero-length IPv6 Address field is incl=
uded by mobile node, the responder MAY respond with zero, one or more P-CSC=
F_IP6_ADDRESS
   attributes. If several P-CSCF_IP6_ADDRESS attributes are provided in one=
 IKEv2 message, there is no implied order among the P-CSCF_IP6_ADDRESS attr=
ibutes.
------

The proposed text is very clear. Thank you



Thanks for a detailed review.

Regards
Sri




Kind regards

Ivo Sedlacek
Ericsson
Mobile +420 608 234 709
ivo.sedlacek@ericsson.com<mailto:ivo.sedlacek@ericsson.com>
www.ericsson.com<http://www.ericsson.com>

This Communication is Confidential. We only send and receive email on the b=
asis of the terms set out at www.ericsson.com/email_disclaimer<http://www.e=
ricsson.com/email_disclaimer>


--_000_39B5E4D390E9BD4890E2B310790061011272F963ESESSMB301erics_
Content-Type: text/html; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
2">
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Arial","sans-serif";
	color:#C0504D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ar=
ial&quot;,&quot;sans-serif&quot;;color:#C0504D">Hello,<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ar=
ial&quot;,&quot;sans-serif&quot;;color:#C0504D"><o:p>&nbsp;</o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ar=
ial&quot;,&quot;sans-serif&quot;;color:#C0504D">I checked draft-gundavelli-=
ipsecme-3gpp-ims-options-03.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ar=
ial&quot;,&quot;sans-serif&quot;;color:#C0504D"><o:p>&nbsp;</o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ar=
ial&quot;,&quot;sans-serif&quot;;color:#C0504D">My comments are resolved in=
 draft-gundavelli-ipsecme-3gpp-ims-options-03<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ar=
ial&quot;,&quot;sans-serif&quot;;color:#C0504D"><o:p>&nbsp;</o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ar=
ial&quot;,&quot;sans-serif&quot;;color:#C0504D">Thank you for taking my com=
ments into account.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ar=
ial&quot;,&quot;sans-serif&quot;;color:#C0504D"><o:p>&nbsp;</o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ar=
ial&quot;,&quot;sans-serif&quot;;color:#C0504D">Kind regards<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ar=
ial&quot;,&quot;sans-serif&quot;;color:#C0504D"><o:p>&nbsp;</o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ar=
ial&quot;,&quot;sans-serif&quot;;color:#C0504D">Ivo Sedlacek<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ar=
ial&quot;,&quot;sans-serif&quot;;color:#C0504D"><o:p>&nbsp;</o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:8.0pt;font-family:&quot;Ari=
al&quot;,&quot;sans-serif&quot;;color:#333333">This Communication is Confid=
ential. We only send and receive email on the basis of the terms set out at
<a href=3D"http://www.ericsson.com/email_disclaimer" title=3D"http://www.er=
icsson.com/email_disclaimer">
www.ericsson.com/email_disclaimer</a> </span><o:p></o:p></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Sri Gund=
avelli (sgundave) [mailto:sgundave@cisco.com]
<br>
<b>Sent:</b> 10. z=E1=F8=ED 2014 17:42<br>
<b>To:</b> Ivo Sedlacek; ipsec@ietf.org<br>
<b>Cc:</b> Jouni Korhonen; Aeneas Dodd-Noble (noblea); baboescu@broadcom.co=
m<br>
<b>Subject:</b> Re: Review of draft-gundavelli-ipsecme-3gpp-ims-options-02<=
o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">Hi Ivo,<o:p></o:p></span></=
p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">Thanks for your response. P=
lease see inline.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">On 9/9/14 4:09 AM, &quot;Iv=
o Sedlacek&quot; &lt;<a href=3D"mailto:ivo.sedlacek@ericsson.com">ivo.sedla=
cek@ericsson.com</a>&gt; wrote:<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<blockquote style=3D"border:none;border-left:solid #B5C4DF 4.5pt;padding:0c=
m 0cm 0cm 4.0pt;margin-left:3.75pt;margin-right:0cm" id=3D"MAC_OUTLOOK_ATTR=
IBUTION_BLOCKQUOTE">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">Hello,<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">I reviewed
<a href=3D"http://tools.ietf.org/id/draft-gundavelli-ipsecme-3gpp-ims-optio=
ns-02.txt">
http://tools.ietf.org/id/draft-gundavelli-ipsecme-3gpp-ims-options-02.txt</=
a> and found the following issues:<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">ISSUE 1: the draft states:<=
o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">These attributes can be<o:p=
></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; used for carry=
ing the IPv4 and IPv6 address of the Proxy-Call Control<o:p></o:p></span></=
p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; and Service fu=
nction (P-CSCF).<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">In 3GPP, P-CSCF abbreviatio=
n stands for &quot;Proxy-Call Session Control Function&quot;.<o:p></o:p></s=
pan></p>
</div>
</blockquote>
<blockquote style=3D"border:none;border-left:solid #B5C4DF 4.5pt;padding:0c=
m 0cm 0cm 4.0pt;margin-left:3.75pt;margin-right:0cm" id=3D"MAC_OUTLOOK_ATTR=
IBUTION_BLOCKQUOTE">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">PROPOSAL 1: state:<o:p></o:=
p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">These attributes can be<o:p=
></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; used for carry=
ing the IPv4 address and IPv6 address of the Proxy-Call Session Control fun=
ction (P-CSCF).<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
</blockquote>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.5pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:#007F00">Ok</span></b><span sty=
le=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quo=
t;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<blockquote style=3D"border:none;border-left:solid #B5C4DF 4.5pt;padding:0c=
m 0cm 0cm 4.0pt;margin-left:3.75pt;margin-right:0cm" id=3D"MAC_OUTLOOK_ATTR=
IBUTION_BLOCKQUOTE">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">ISSUE 2: the draft states:<=
o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">When an IPSec gateway deliv=
ers these<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; attributes to =
an IPsec client, it can obtain the IPv4 and/or IPv6<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; address of the=
 P-CSCF server located in the home network.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">The P-CSCF does not necessa=
rily need to be located in the home network. In roaming situations, the P-C=
SCF can also be in visited network.&nbsp;&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">Example: User has a contrac=
t with an European operator. The user with its user equipment (UE) is in Ja=
pan and uses network of a Japanese operator. In such use
 case, the ePDG entity, the PGW entity and P-CSCF can all be in visited net=
work (i.e. Japanese operator network).<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">PROPOSAL 2: state:<o:p></o:=
p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">When an IPSec gateway deliv=
ers these<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; attributes to =
an IPsec client, the IPsec client can obtain the IPv4 and/or IPv6<o:p></o:p=
></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; address of the=
 P-CSCF server located in the 3GPP network.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
</blockquote>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<div>
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.5pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:#007F00">The &quot;home&quot; n=
etwork terminology was not truly intended to reflect the 3GPP roaming archi=
tecture. Its just to say the configuration comes from the PGW/LMA.&nbsp;</s=
pan></b><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&qu=
ot;sans-serif&quot;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.5pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:#007F00">But, agree with the ch=
ange.</span></b><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&q=
uot;,&quot;sans-serif&quot;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
</div>
<blockquote style=3D"border:none;border-left:solid #B5C4DF 4.5pt;padding:0c=
m 0cm 0cm 4.0pt;margin-left:3.75pt;margin-right:0cm" id=3D"MAC_OUTLOOK_ATTR=
IBUTION_BLOCKQUOTE">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">ISSUE 3: the draft states:<=
o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; The Third Gene=
ration Partnership Project (3GPP) S2b reference point<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; [TS23402], spe=
cified by the 3GPP system architecture defines a<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; mechanism for =
allowing a mobile node (MN) attached in an untrusted<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; non-3GPP IP Ac=
cess Network to securely connect to the 3GPP home<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; network and ac=
cess IP services.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">When roaming, the UE can ac=
cess IP services in the 3GPP home network or 3GPP visited network. ePDG can=
 be in visited or home network - see&nbsp;&nbsp;<a href=3D"http://www.3gpp.=
org/ftp/Specs/archive/23_series/23.402/23402-c50.zip">http://www.3gpp.org/f=
tp/Specs/archive/23_series/23.402/23402-c50.zip</a>
 section 4.5.4. If so, P-GW and P-CSCF can also be in the visited network.<=
o:p></o:p></span></p>
</div>
</blockquote>
<blockquote style=3D"border:none;border-left:solid #B5C4DF 4.5pt;padding:0c=
m 0cm 0cm 4.0pt;margin-left:3.75pt;margin-right:0cm" id=3D"MAC_OUTLOOK_ATTR=
IBUTION_BLOCKQUOTE">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">PROPOSAL 3: state:<o:p></o:=
p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; The Third Gene=
ration Partnership Project (3GPP) S2b reference point<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; [TS23402], spe=
cified by the 3GPP system architecture defines a<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; mechanism for =
allowing a mobile node (MN) attached in an untrusted<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; non-3GPP IP Ac=
cess Network to securely connect to a 3GPP
<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; network and ac=
cess IP services.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
</blockquote>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<div>
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.5pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:#007F00">The &quot;home&quot; n=
etwork terminology was not truly intended to reflect the 3GPP roaming archi=
tecture. Its just to say the configuration comes from the PGW/LMA.
</span></b><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,=
&quot;sans-serif&quot;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<div>
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.5pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:#007F00">But, agree with the ch=
ange.</span></b><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&q=
uot;,&quot;sans-serif&quot;"><o:p></o:p></span></p>
</div>
</div>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<blockquote style=3D"border:none;border-left:solid #B5C4DF 4.5pt;padding:0c=
m 0cm 0cm 4.0pt;margin-left:3.75pt;margin-right:0cm" id=3D"MAC_OUTLOOK_ATTR=
IBUTION_BLOCKQUOTE">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">ISSUE 4: the draft states:<=
o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; A mobile node =
in this scenario may potentially need to access the IP<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; Multimedia Sub=
system (IMS) services in the home network.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">P-CSCF can also be in visit=
ed network.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">PROPOSAL 4: state:<o:p></o:=
p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; A mobile node =
in this scenario may potentially need to access the IP<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; Multimedia Sub=
system (IMS) services in the 3GPP network.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
</blockquote>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.5pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:#007F00">Ok</span></b><span sty=
le=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quo=
t;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<blockquote style=3D"border:none;border-left:solid #B5C4DF 4.5pt;padding:0c=
m 0cm 0cm 4.0pt;margin-left:3.75pt;margin-right:0cm" id=3D"MAC_OUTLOOK_ATTR=
IBUTION_BLOCKQUOTE">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">ISSUE 5: the draft states:<=
o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; Proxy-Call Ses=
sion Control Function (P-CSCF)<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;The P-CSCF is the entry point to the 3GPP IMS (IP Multimedia<o:p><=
/o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;Subsystem) domain and serves as the outbound proxy server for the<=
o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;mobile node.&nbsp;&nbsp;The mobile node attaches to the P-CSCF pri=
or to<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;performing IMS registrations and initiating SIP sessions.<o:p></o:=
p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">Problems:<o:p></o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">1) 3GPP IMS is not a domain=
.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">2) The mobile node does NOT=
 attach to P-CSCF prior to performing the IMS registration. Instead, the re=
gistration with IMS is the request for &quot;attachment&quot; to IMS.<o:p><=
/o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">PROPOSAL 5: state:<o:p></o:=
p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; Proxy-Call Ses=
sion Control Function (P-CSCF)<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;The P-CSCF is the entry point to the 3GPP IMS (IP Multimedia<o:p><=
/o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;Subsystem)&nbsp;&nbsp;and serves as the SIP outbound proxy for the=
<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;mobile node.&nbsp;&nbsp;The mobile node performs SIP registration =
to 3GPP IMS and initiates SIP sessions via a P-CSCF.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
</blockquote>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.5pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:#007F00">Thanks. That was a typ=
o. It should have said, &quot;the mobile node attaches to the 3GPP network =
...&quot;.</span></b><span style=3D"font-size:10.5pt;font-family:&quot;Cali=
bri&quot;,&quot;sans-serif&quot;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.5pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:#007F00">Agree with the text.</=
span></b><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&q=
uot;sans-serif&quot;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<blockquote style=3D"border:none;border-left:solid #B5C4DF 4.5pt;padding:0c=
m 0cm 0cm 4.0pt;margin-left:3.75pt;margin-right:0cm" id=3D"MAC_OUTLOOK_ATTR=
IBUTION_BLOCKQUOTE">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">ISSUE 6: the draft states:<=
o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">Multiple P-CSCF<o:p></o:p><=
/span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; servers MAY be=
 requested by including a single instance of an empty<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; P-CSCF_IP4_ADD=
RESS attribute with zero-length IPv4 Address field.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; The responder =
MAY respond with zero or more P-CSCF_IP4_ADDRESS<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; attributes, an=
d there is no implied order in the response.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">IMO, the 1st sentence above=
 is misleading as it suggests that the mobile node has a choise to request =
one P-CSCF IPv4 address or to request multiple P-CSCF IPv4
 addresses. However, in my reading of the rest of the draft, the mobile nod=
e has just one choise - request P-CSCF IPv4 addresses and receive zero, one=
 or several P-CSCF IPv4 addresses.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">PROPOSAL 6: state:<o:p></o:=
p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">If an instance of an empty<=
o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; P-CSCF_IP4_ADD=
RESS attribute with zero-length IPv4 Address field is included by mobile no=
de, the responder MAY respond with zero, one or more P-CSCF_IP4_ADDRESS<o:p=
></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; attributes. If=
 several P-CSCF_IP4_ADDRESS attributes are provided in one IKEv2 message, t=
here is no implied order among the P-CSCF_IP4_ADDRESS attributes.<o:p></o:p=
></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
</blockquote>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.5pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:#007F00">The proposed text is v=
ery clear. Thank you</span></b><span style=3D"font-size:10.5pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<blockquote style=3D"border:none;border-left:solid #B5C4DF 4.5pt;padding:0c=
m 0cm 0cm 4.0pt;margin-left:3.75pt;margin-right:0cm" id=3D"MAC_OUTLOOK_ATTR=
IBUTION_BLOCKQUOTE">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">ISSUE 7: the draft states:<=
o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">Multiple P-CSCF<o:p></o:p><=
/span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; servers MAY be=
 requested by including a single instance of an empty<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; P-CSCF_IP6_ADD=
RESS attribute with zero-length IPv6 Address field.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; The responder =
MAY respond with zero or more P-CSCF_IP6_ADDRESS<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; attributes, an=
d there is no implied order in the response.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">IMO, the 1st sentence above=
 is misleading as it suggests that the mobile node has a choise to request =
one P-CSCF IPv6 address or to request multiple P-CSCF IPv6
 addresses. However, in my reading of the rest of the draft, the mobile nod=
e has just one choise - request P-CSCF IPv6 addresses and receive zero, one=
 or several P-CSCF IPv6 addresses.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">PROPOSAL 7: state:<o:p></o:=
p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">If an instance of an empty<=
o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; P-CSCF_IP6_ADD=
RESS attribute with zero-length IPv6 Address field is included by mobile no=
de, the responder MAY respond with zero, one or more P-CSCF_IP6_ADDRESS<o:p=
></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">&nbsp;&nbsp; attributes. If=
 several P-CSCF_IP6_ADDRESS attributes are provided in one IKEv2 message, t=
here is no implied order among the P-CSCF_IP6_ADDRESS attributes.<o:p></o:p=
></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">------<o:p></o:p></span></p=
>
</div>
</blockquote>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<div>
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.5pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;;color:#007F00">The proposed text is v=
ery clear. Thank you</span></b><span style=3D"font-size:10.5pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;"><o:p></o:p></span></p>
</div>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">Thanks for a detailed revie=
w.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">Regards<o:p></o:p></span></=
p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">Sri<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<blockquote style=3D"border:none;border-left:solid #B5C4DF 4.5pt;padding:0c=
m 0cm 0cm 4.0pt;margin-left:3.75pt;margin-right:0cm" id=3D"MAC_OUTLOOK_ATTR=
IBUTION_BLOCKQUOTE">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">Kind regards<o:p></o:p></sp=
an></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">Ivo Sedlacek<o:p></o:p></sp=
an></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">Ericsson<o:p></o:p></span><=
/p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">Mobile &#43;420 608 234 709=
<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><a href=3D"mailto:ivo.sedla=
cek@ericsson.com">ivo.sedlacek@ericsson.com</a><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><a href=3D"http://www.erics=
son.com">www.ericsson.com</a><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black">This Communication is Confi=
dential. We only send and receive email on the basis of the terms set out a=
t
<a href=3D"http://www.ericsson.com/email_disclaimer">www.ericsson.com/email=
_disclaimer</a><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p=
>
</div>
</blockquote>
</div>
</body>
</html>

--_000_39B5E4D390E9BD4890E2B310790061011272F963ESESSMB301erics_--


From nobody Thu Sep 11 03:55:21 2014
Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A605F1A06D3 for <ipsec@ietfa.amsl.com>; Thu, 11 Sep 2014 03:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.773
X-Spam-Level: 
X-Spam-Status: No, score=-2.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbxH-FP44qtz for <ipsec@ietfa.amsl.com>; Thu, 11 Sep 2014 03:55:18 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35CBA1A06C7 for <ipsec@ietf.org>; Thu, 11 Sep 2014 03:55:17 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s8BAqAqX000797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Sep 2014 13:52:10 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s8BAq9px014680; Thu, 11 Sep 2014 13:52:09 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-ID: <21521.32473.586498.78908@fireball.kivinen.iki.fi>
Date: Thu, 11 Sep 2014 13:52:09 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: dharmanandana pothulam <dharmanandana.pothulam@huawei.com>
In-Reply-To: <3F00A55B1B111141BAE547DB25D09FE254570D36@szxeml513-mbx.china.huawei.com>
References: <3F00A55B1B111141BAE547DB25D09FE254570D36@szxeml513-mbx.china.huawei.com>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 18 min
X-Total-Time: 19 min
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Y6OCTP3K_BFGPp-mY6xXv3XzYNc
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, Sameer varshney <sameer.varshney@huawei.com>, Liangjicheng <liangjicheng@huawei.com>
Subject: [IPsec]  IKEv1 Interop issue: Transform number mismatch
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Sep 2014 10:55:20 -0000

dharmanandana pothulam writes:
> We are facing one IKEv1 interop issue. The issue is that Responder
> (checkpoint SeGW) not retaining the transform numbers received from
> the initiator (huawei base station), SeGW replies with its own
> transform number.

IKEv1 was obsoleted by IKEv2 in 2005, you should try to work on
supporting current IPsec, not something that was obsoleted almost ten
years ago...

> Huawei base station compares received transform number with one of
> the transform numbers sent initially along with other attributes,
> this is inline with the RFC 2408 section 4.2 statement (The
> initiator MUST verify that the Security Association payload received
> from the responder matches one of the proposals sent initially).

That check is really only meant to check the actual proposal
information, i.e. the cipher selected is one of the proposed one,
transform # or proposal # are not part of that check. The idea of the
check is to make sure that the selected proposal is something that is
acceptable by the initiator policy.

> One more point rfc says =E2=80=9CThe responder SHOULD retain the Prop=
osal #
> field in the Proposal payload and the Transform # field in each
> Transform payload of the selected Proposal".

Which clearly says that they can also be different. So initiator can
use those numbers to quickly see which of the hundred proposal was
selected, but if they do not match, you still need to do full check
and find if any of the proposals you sent matches the incoming
proposal.

> As I understand This transform number helps to direct to the correct
> SA attributes in initiator side.

Yes, it can be used as optimization, but as other end is not mandated
to return same number, you can only use it as optimization and if that
optimization fails, you need to do full search.=20

> why some vendors not retaining the transform number sent by
> initiator=3F if not followed, Do we see usefulness of the transform
> number received at initiator side=3F Can we drop the exchange if
> correct transform number not received=3F

That I cannot answer. Most likely because of the old code structure or
similar, and as we are talking about the protocol obsoleted almost ten
years ago, I do not expect vendors to be very interested in changing
their products now. So if interoperability with obsoleted protocol
with all vendors is requirement for you, then you need to do full
search when check with the transform number fails.=20

Note, also that another funny thing about IKEv1 is that it says that
those numbers need to be "monotonically increasing numbers". That
means that they do not need to be incremented by one, valid numbers
can also be 1, 4, 66, 213... There are implementations out there that
do also that, and also the first number can be 0, 1 or any other
value...

In IKEv2 this was fixed so that first proposal number must be 1, and
they must increment by one, and responder must return same proposal
number back. In IKEv2 there is no transform numbers as transform
substructure is quite different.
--=20
kivinen@iki.fi


From nobody Thu Sep 11 04:02:45 2014
Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2501D1A8919 for <ipsec@ietfa.amsl.com>; Thu, 11 Sep 2014 04:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.123
X-Spam-Level: *
X-Spam-Status: No, score=1.123 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wtf5FYGlA9ZE for <ipsec@ietfa.amsl.com>; Thu, 11 Sep 2014 04:02:42 -0700 (PDT)
Received: from mail.kivinen.iki.fi (unknown [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613141A06B8 for <ipsec@ietf.org>; Thu, 11 Sep 2014 04:02:40 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s8BB2X4C023806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Sep 2014 14:02:33 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s8BB2X1C013496; Thu, 11 Sep 2014 14:02:33 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21521.33097.685133.508782@fireball.kivinen.iki.fi>
Date: Thu, 11 Sep 2014 14:02:33 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
In-Reply-To: <54113486.9020601@gmail.com>
References: <CAEX11nYFEj-f8m-8fK-j7FH-EDavG0XgmJwonFMj_V_5eJHFzQ@mail.gmail.com> <54113486.9020601@gmail.com>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 6 min
X-Total-Time: 6 min
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/BDwAFwe49vR29Ys9_wSRI-t-qmk
Cc: ipsec@ietf.org, Rahul Vaidya <rahul.stds@gmail.com>
Subject: Re: [IPsec] Mandatory Public Key based authentication with EAP
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Sep 2014 11:02:44 -0000

Yaron Sheffer writes:
> This is why RFC 5998 is listed as "updates 5996". So RFC 5998 does apply 
> here. Note that it only applies in specific cases, and for specific EAP 
> methods.
> 
> Yes, we should have updated the text in RFC 5996 to refer to 5998, but 
> we forgot. Sigh.

Hmm.. I hope this does not mean we should update
draft-kivinen-ikev2-rfc5996bis (now in AUTH48) to say something about
this?

The RFC 5998 is standard track protocol that extends IKEv2 by
including new notifications to negotiate the mutual EAP
authentication, and also changes the payloads sent in the exchanges.

The current text in the draft is not incorrect, as if you follow the
protocol described in this draft, then the in draft is correct:

   An implementation using EAP MUST also use a public-key-based
   authentication of the server to the client before the EAP
   authentication begins, even if the EAP method offers mutual
   authentication.  This avoids having additional IKEv2 protocol
   variations and protects the EAP data from active attackers.

What we could do, is to add reference to the RFC5998 there, but I
think it might not be needed, as RFC5998 is clearly an extension to
the IKEv2, and we do not need to list all extensions to IKEv2 in the
specification.

What do others think? If we would earlier in the publication process,
I would say go for it, but adding this kind of text in AUTH48 is not
something I would like to be doing... 
-- 
kivinen@iki.fi


From nobody Thu Sep 11 04:06:15 2014
Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315481A8934 for <ipsec@ietfa.amsl.com>; Thu, 11 Sep 2014 04:06:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.773
X-Spam-Level: 
X-Spam-Status: No, score=-2.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wODN5hTc70Cf for <ipsec@ietfa.amsl.com>; Thu, 11 Sep 2014 04:06:13 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9275F1A8930 for <ipsec@ietf.org>; Thu, 11 Sep 2014 04:06:12 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s8BB6Axh007977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Sep 2014 14:06:10 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s8BB6AjP023617; Thu, 11 Sep 2014 14:06:10 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21521.33314.11281.192320@fireball.kivinen.iki.fi>
Date: Thu, 11 Sep 2014 14:06:10 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
In-Reply-To: <540CA9B2.3090807@gmail.com>
References: <540CA9B2.3090807@gmail.com>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 2 min
X-Total-Time: 2 min
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/78XNkE_IZ9YzAfzYP9vJrlc4PvE
Cc: ipsec <ipsec@ietf.org>
Subject: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Sep 2014 11:06:14 -0000

Yaron Sheffer writes:
> This is a call for adopting draft-smyslov-ipsecme-ikev2-null-auth as a 
> WG document. Please respond to this mail with a Yes or No and a short 
> rationale, at latest by Friday Sep. 12.

I have not really had time to concentrate on this topic yet, but I
think this kind of extension would be useful, and I especially think
one way authentication would be useful in the IoT contexts. I am not
that convinced that no authentication at all is that useful, but I
might be wrong (there are complicated policy issues with that, which
might require more work).

I support taking this document as WG document (i.e. as first version,
that can then be worked on later). 
-- 
kivinen@iki.fi


From nobody Thu Sep 11 08:53:33 2014
Return-Path: <mcr@sandelman.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3501A895F for <ipsec@ietfa.amsl.com>; Thu, 11 Sep 2014 08:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.553
X-Spam-Level: 
X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKT9ZJaYcv8Y for <ipsec@ietfa.amsl.com>; Thu, 11 Sep 2014 08:53:27 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1704F1A02F5 for <ipsec@ietf.org>; Thu, 11 Sep 2014 08:53:27 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 534C82002D for <ipsec@ietf.org>; Thu, 11 Sep 2014 11:57:58 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 1FFEA63AE9; Thu, 11 Sep 2014 11:53:26 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 05479637FC for <ipsec@ietf.org>; Thu, 11 Sep 2014 11:53:26 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: ipsec <ipsec@ietf.org>
In-Reply-To: <21521.33314.11281.192320@fireball.kivinen.iki.fi>
References: <540CA9B2.3090807@gmail.com> <21521.33314.11281.192320@fireball.kivinen.iki.fi>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Thu, 11 Sep 2014 11:53:26 -0400
Message-ID: <23504.1410450806@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/sjmKpJ-4cIzI_BZZb1sr4vWzIjU
Subject: Re: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Sep 2014 15:53:29 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


Tero Kivinen <kivinen@iki.fi> wrote:
    >> This is a call for adopting draft-smyslov-ipsecme-ikev2-null-auth as=
 a
    >> WG document. Please respond to this mail with a Yes or No and a short
    >> rationale, at latest by Friday Sep. 12.

    > I have not really had time to concentrate on this topic yet, but I
    > think this kind of extension would be useful, and I especially think
    > one way authentication would be useful in the IoT contexts.=20

I *do* think that no authentication will become useful for some things.

I wonder if we will see protocols where is the a cycle of null-auth IKEv2,
followed by some non-null-auth once the two parties decide that they might
want to do something more interesting.  (I liken this to two dogs sniffing
each other's butts... and then.. well. that might be safe-for-work)

I don't think IoT will be one of the situations.

Adopt the document.

=2D-=20
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-




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

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

iQEVAwUBVBHFc4CLcPvd0N1lAQKcWAf/dIhwL6ra1TjPs/HLWu2iVxIikBrLknmm
8b38XsRo+0Uk409ciIL5e14rBybCtzb1PYnZCvQLgi4aCEBrrqo7ibMsnaiRM2U1
2YzqV9xGVUBFgmshCxvhrn0g1rhbbriq71Z8HSwOhidg3PAXPXyHLK0ZlU0CrI1g
xAZtS8bHjA+Kud8bCkGpZbpkMWRc8yO48A7oHjHm/mp/GBwOFaYi0w5oyXCZkMJg
oXWCO2qMzve5LAbCqBjFV+MJG+Uw3A+sk8tWuNyTpggWnqboyU5nesFJwIF1LY5W
Z1QMYS9ccQqKljUI/90A3KV+d4nY0vmRZzuxzpJ3mS95SCZgqFHnOQ==
=adVN
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Fri Sep 12 05:43:33 2014
Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6221A06DF for <ipsec@ietfa.amsl.com>; Fri, 12 Sep 2014 05:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.252
X-Spam-Level: 
X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X_FwKW3kg465 for <ipsec@ietfa.amsl.com>; Fri, 12 Sep 2014 05:43:31 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08D9A1A06DB for <ipsec@ietf.org>; Fri, 12 Sep 2014 05:43:31 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CC98880111; Fri, 12 Sep 2014 08:43:28 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1410525808; bh=6vI0THkNwRV2tp0ZYkcojpctayoB1gZlslP0fPBF9UI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=pZglHMjxxoo0Lj14z1D5j46lKxu5Hbb1vDyohaYSjZh08bekAMrdAI7MI+q6vVbFs 8cJMDQHoUMnGVPm1hqEdvKsrenVoeWSRjLtft7qr1WDd8p3DXXfc2SQc/Y3J0JZidz TcH4CZwDynVlqFemrKH++8Kxt7V1ibVMNEV4uICs=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s8CChRW9017731; Fri, 12 Sep 2014 08:43:27 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Fri, 12 Sep 2014 08:43:27 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
In-Reply-To: <54114E0E.80108@gmail.com>
Message-ID: <alpine.LFD.2.10.1409120839100.17541@bofh.nohats.ca>
References: <540CA9B2.3090807@gmail.com> <BE175F90-68B6-4731-B32E-BA9EF3F3BAD8@dell.com> <CADi0yUM3ESC9A1WaJJZ5QKrAeUd-wiNLFRdpRUYp5vGXir-A6Q@mail.gmail.com> <6E9345DD1E9A43158A0DD61F96C09741@buildpc> <CADi0yUMQftcsij+aH5XB2O97LZ7fVJeq2jNTHqK5kvsaZuSWYQ@mail.gmail.com> <54114E0E.80108@gmail.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/aOOK2wETwOOfbQe2XHhSdhl-Dbo
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Sep 2014 12:43:32 -0000

On Thu, 11 Sep 2014, Yaron Sheffer wrote:

> The document's introduction does give the impression that the main point of 
> this document is one-way auth, but I think most of the people who support 
> this document are more interested in fully anonymous key exchange.

Both are definately within the scope of what we are thinking about,
although we would really prefer one-way sees wide adoption and
deployment.

Another use case that has come up is cloud instance deployments, where
images are part of a group, and individual hosts booted from the same
image don't really have a unique identity. These cases don't fall
clearly within mutual or one-sided auth.

Paul


From nobody Fri Sep 12 09:11:12 2014
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3321A06B0 for <ipsec@ietfa.amsl.com>; Fri, 12 Sep 2014 09:11:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.276
X-Spam-Level: 
X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCvEomBQKZWZ for <ipsec@ietfa.amsl.com>; Fri, 12 Sep 2014 09:11:08 -0700 (PDT)
Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 279E31A02E9 for <ipsec@ietf.org>; Fri, 12 Sep 2014 09:11:08 -0700 (PDT)
Received: by mail-we0-f180.google.com with SMTP id t60so999422wes.25 for <ipsec@ietf.org>; Fri, 12 Sep 2014 09:11:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=zzRXZ63vBZHPrNzKRwVw2jcBfOfnnTAGILEdROuLPYo=; b=J3O5njCUYu8rOPKsfoomU7c7kkdL91WytAEm+eiJ0E6cy9zWwp+Kqy0iP8pxLdW4MA cKVFRAEi6lcPgqW1/62ilnyFuYRfWCeHBG6vVp6qMQcFCU3gJ9jA00Vm2lEYS5x5GldK 4HjcK7YFiTR7FXYHdmg+CByLbHZrde5nKAjCFy8DKt/UOL+k2Mg2euDIwqE2p32eGQj2 S0UdL7+eqn1eOP1dA8JpZOYcaiYPuDHFCB9oi1D53Xwtl1hFDZk0S+A2tQPiA+14IUMI e/9TZZ91f81V1EfB6Aychf1YsUA+JVfmIx61DVqMERhRUyi5BgRaaiUP8Uf+RYlIkTWc RvXw==
X-Received: by 10.180.188.70 with SMTP id fy6mr3677014wic.25.1410538266802; Fri, 12 Sep 2014 09:11:06 -0700 (PDT)
Received: from [10.0.0.9] (bzq-79-177-135-86.red.bezeqint.net. [79.177.135.86]) by mx.google.com with ESMTPSA id bt9sm4988712wjc.44.2014.09.12.09.11.05 for <ipsec@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Sep 2014 09:11:05 -0700 (PDT)
Message-ID: <54131B16.6060406@gmail.com>
Date: Fri, 12 Sep 2014 19:11:02 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: IPsecME WG <ipsec@ietf.org>
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/-jLRmzkp05U5mBKNiZziZP86S5Q
Subject: [IPsec] Adoption: The NULL Authentication Method in IKEv2 Protocol
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Sep 2014 16:11:09 -0000

<html style="direction: ltr;">
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    <style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
  </head>
  <body style="direction: ltr;" bidimailui-charset-is-forced="true"
    text="#000000" bgcolor="#FFFFFF">
    Based on the WG discussion this week, there is clear support for
    adopting this draft as a WG document. We request the author to
    re-publish the current text as a WG document.<br>
    <br>
    Several issues were raised during the call for adoption, and we will
    surely discuss them on the list once the draft is published.<br>
    <br>
    Thanks,<br>
        <br>
        Paul and Yaron<br>
  </body>
</html>


From nobody Fri Sep 12 09:16:42 2014
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB511A06D8 for <ipsec@ietfa.amsl.com>; Fri, 12 Sep 2014 09:16:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.276
X-Spam-Level: 
X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XD6XLknthOhf for <ipsec@ietfa.amsl.com>; Fri, 12 Sep 2014 09:16:39 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 060691A02F4 for <ipsec@ietf.org>; Fri, 12 Sep 2014 09:16:38 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id bs8so961754wib.4 for <ipsec@ietf.org>; Fri, 12 Sep 2014 09:16:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=XWg7w7KcFjS5AHB4x2im/X4dIyKq/T86pYv6NZ5Xmh0=; b=RwL67HcaPxru6ZmrQpO4CgKvsF9bDIguEGZ6u3nfTL8d9AXnSQ3/ZDi1gycnOw3feu Sr1D6B8/MCMpgeP08f0/kvGfdY03sZ6qgOTHXZ3Ca47cRwpo+LQhr4BUl1/9f4nhxUj0 g9QW5oHxd9AAZg1t92pcGY0X6Yok+tWn1FgLBVPRKD5Q+rvz/nn08pFWS73z9P1rscsT 2HfNxLpfglcK29x9wU4qSvJyTL05KWTx+nuknoAzy+5YuMWKXIBvdkKZYRUVra8Rpo94 PFUxNS7L4pgK3ts7asB5QXzs8onObnxwNgMA9O/UEaltCmjigXh8dk9t5KPqpAMm3mAs Zy9A==
X-Received: by 10.180.211.102 with SMTP id nb6mr3556449wic.11.1410538597736; Fri, 12 Sep 2014 09:16:37 -0700 (PDT)
Received: from [10.0.0.9] (bzq-79-177-135-86.red.bezeqint.net. [79.177.135.86]) by mx.google.com with ESMTPSA id h3sm5027771wjz.24.2014.09.12.09.16.36 for <ipsec@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Sep 2014 09:16:37 -0700 (PDT)
Message-ID: <54131C57.2060605@gmail.com>
Date: Fri, 12 Sep 2014 19:16:23 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: ipsec <ipsec@ietf.org>
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/wuHqs7U8nslxnIiMPQejxnBfKxI
Subject: [IPsec] Call for adoption: MOBIKEv2: MOBIKE extension for Transport mode
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Sep 2014 16:16:40 -0000

<html style="direction: ltr;">
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    <style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
  </head>
  <body style="direction: ltr;" bidimailui-charset-is-forced="true"
    text="#000000" bgcolor="#FFFFFF">
    <pre style="margin: 0em;">Dear working group,

</pre>
    <tt>This is a call for adopting draft-mglt-ipsecme-mobikev2 as a </tt><tt>WG
      document. Please respond to this mail with a Yes or No and a short
    </tt><tt>rationale, at latest by Friday Sep. 19.<br>
      <br>
    </tt>
    <pre style="margin: 0em;">Thanks,
	Yaron

</pre>
  </body>
</html>


From nobody Fri Sep 12 11:03:10 2014
Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DCE1A86E5 for <ipsec@ietfa.amsl.com>; Fri, 12 Sep 2014 11:03:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.652
X-Spam-Level: 
X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EM1niT2HcmMs for <ipsec@ietfa.amsl.com>; Fri, 12 Sep 2014 11:03:01 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B30DA1A82E2 for <ipsec@ietf.org>; Fri, 12 Sep 2014 11:02:41 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6640A80111; Fri, 12 Sep 2014 14:02:40 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1410544960; bh=TPCWD9dIAN/keuqLQz0zWtXdAT82MeQqFqrAjflYAVQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MepO6qszQiBUI5VNG2/XATlkwfjxg59UD86qjMTsxr38T+DBnQGcg5ECZ5XiPGQyh EaCmf2ibEs/hCWPh03GMru6ASITmRBFck/ip+EVwJvWyIAT8kQNZEJerByblOYs05b X3o8+iyWRnbq0RSWYzUCuQH3HgOFEZtv/3v+BVBU=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s8CI2dl0031993; Fri, 12 Sep 2014 14:02:39 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Fri, 12 Sep 2014 14:02:39 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
In-Reply-To: <54131C57.2060605@gmail.com>
Message-ID: <alpine.LFD.2.10.1409121350180.31178@bofh.nohats.ca>
References: <54131C57.2060605@gmail.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Q_mGwDJJ42ROBvp4bOM2LyZJ11Q
Cc: ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] Call for adoption: MOBIKEv2: MOBIKE extension for Transport mode
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Sep 2014 18:03:07 -0000

On Fri, 12 Sep 2014, Yaron Sheffer wrote:

> This is a call for adopting draft-mglt-ipsecme-mobikev2 as a WG document. Please respond to this mail with a Yes or No and a short
> rationale, at latest by Friday Sep. 19.

This document confuses me.

It seems section 4 to 7 are about much more than just transport mode. It
seems to (re?)introduce versioning, non-transport notify payloads, etc.

MOBIKE is about keeping your assigend address with you, making your
inner IP consistent regardless of the outer IP. That makes no sense
with transport mode, which is tied to your ephemeral outer address.

Transport mode IPsec is terrible idea in todays NATed world. It should
die, not see more use. The NAT issues are not at all mentioned in this
draft. What if two clients connect to the same MOBIKE VPN server with
the same internal IP of 10.1.2.3?

The use case is "saving a few bytes", which to me seems very weak.

It would only work with UDP, not TCP. For UDP, doesn't recvfrom() and
recvmsg() family deal with changing IPs? IKE and DNS servers already
use this to listen on ANY and reply to the address of the received
packet.

This is a lot of specification and code and possible interop problems
for a use case of "saving a few bytes on some UDP packets".

It is possible further discussion might convince me otherwise, although
not likely. I'm happy to discuss this item further as a working group
if adoption now means we can still decide it is not a good idea later.
If adoption to the WG now means we must end up with some kind of spec,
than I would rather not see adoption now.

Paul


From nobody Sat Sep 13 11:20:29 2014
Return-Path: <mglt.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9921A006D for <ipsec@ietfa.amsl.com>; Sat, 13 Sep 2014 11:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXThUoSDJ0dr for <ipsec@ietfa.amsl.com>; Sat, 13 Sep 2014 11:20:14 -0700 (PDT)
Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3858E1A0060 for <ipsec@ietf.org>; Sat, 13 Sep 2014 11:20:14 -0700 (PDT)
Received: by mail-we0-f176.google.com with SMTP id q58so2200317wes.21 for <ipsec@ietf.org>; Sat, 13 Sep 2014 11:20:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dCDdW8E4IZBW7qVFChppJMC7f0PoEVjxO+EeyfLG0Uw=; b=UlUBLIbC2OkTwhM/kuoqQi9+YhONyKHAaTS/eecq9woIA/Eh5WaOJRb3x3VXow0PRE 8AXIW3O5RENKaa/ZCX+Fe7ZJfddzsLi+Fjgpa7AENRU+Bzc97ofHRmzd3vOx7xmJUYRm LsyUq0SK7QgJVwcVMrRmBMzZp4WOxOm6iOQ0EthanuVhVzjlyouKXGIOPH3vVlhceJWZ qdqjFXbc5VDYXNeSzZPpx3dVo7Op2e2fIIWb/zqpS9TjWhenfbwZ5aPkshbSX8dNT8nW 8w0nIx+ZuyAF/cSTibwDJ17DvwIKGkywESUx0zBTYd/rPdqucptBvgGdHn7/x8FcGqH8 5wvA==
MIME-Version: 1.0
X-Received: by 10.194.9.228 with SMTP id d4mr20382770wjb.99.1410632412879; Sat, 13 Sep 2014 11:20:12 -0700 (PDT)
Received: by 10.194.137.67 with HTTP; Sat, 13 Sep 2014 11:20:12 -0700 (PDT)
In-Reply-To: <alpine.LFD.2.10.1409121350180.31178@bofh.nohats.ca>
References: <54131C57.2060605@gmail.com> <alpine.LFD.2.10.1409121350180.31178@bofh.nohats.ca>
Date: Sat, 13 Sep 2014 20:20:12 +0200
Message-ID: <CADZyTkm0BpZGviYHoYOK8o3JgRBzmAgnm5W8jEoQCZ+mS+T=5w@mail.gmail.com>
From: Daniel Migault <mglt.ietf@gmail.com>
To: Paul Wouters <paul@nohats.ca>
Content-Type: multipart/alternative; boundary=047d7b4508a8e0de9f0502f67327
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/XYTWf8WN39_7hEU2tQ77IF_ch6k
Cc: ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] Call for adoption: MOBIKEv2: MOBIKE extension for Transport mode
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Sep 2014 18:20:18 -0000

--047d7b4508a8e0de9f0502f67327
Content-Type: text/plain; charset=UTF-8

Hi Paul,

Thank you for raising the questions, that gives me he opportunity to
clarify what have been discussed/agreed in Toronto.

As an author I am supporting the adoption of the document as a WG document.

In the Toronto meeting, we agreed that MOBIKE versionning must be removed
in the next version of the draft. We also agreed that Security
Consideration should discuss more in detail the exposure of the IP
addresses. All these will be part of the next version.

The next version of the draft will define how MOBIKE and the
USE_TRANSPORT_MODE Notify Payload work together. As a result, they will be
no MOBIKE versions, the spec will be much simpler, and we will still be
fully interoperable / compatible with existing code of MOBIKE -- i.e. code
that has not been updated.

>From RFC5996 section 1.3.1, the default IPsec mode is the Tunnel mode. When
a USE_TRANSPORT_MODE Notify Payload is received. "It requests that the
Child SA use transport mode rather than tunnel mode for the SA created. If
the request is accepted, the response MUST also include a notification of
type USE_TRANSPORT_MODE. If the responder declines the request, the Child
SA will be established in tunnel mode. "

As a result, currently, when one receives USE_TRANSPORT_MODE and
MOBIKE_SUPPORTED, it has to chose between supporting MOBIKE or the
transport mode. The next version of the draft, will make possible to
respond USE_TRANSPORT_MODE and MOBIKE_SUPPORTED. In all other cases,
nothing is changed.

Motivations for this are UDP (mostly DNS) but also GRE tunnels. In our
opinion, for the DNS use case, saving bytes matters especially when only
the responses is returned over a degraded link like WLAN.


BR,
Daniel


On Fri, Sep 12, 2014 at 8:02 PM, Paul Wouters <paul@nohats.ca> wrote:

> On Fri, 12 Sep 2014, Yaron Sheffer wrote:
>
>  This is a call for adopting draft-mglt-ipsecme-mobikev2 as a WG document.
>> Please respond to this mail with a Yes or No and a short
>> rationale, at latest by Friday Sep. 19.
>>
>
> This document confuses me.
>
> It seems section 4 to 7 are about much more than just transport mode. It
> seems to (re?)introduce versioning, non-transport notify payloads, etc.
>
> MOBIKE is about keeping your assigend address with you, making your
> inner IP consistent regardless of the outer IP. That makes no sense
> with transport mode, which is tied to your ephemeral outer address.
>
> Transport mode IPsec is terrible idea in todays NATed world. It should
> die, not see more use. The NAT issues are not at all mentioned in this
> draft. What if two clients connect to the same MOBIKE VPN server with
> the same internal IP of 10.1.2.3?
>
> The use case is "saving a few bytes", which to me seems very weak.
>
> It would only work with UDP, not TCP. For UDP, doesn't recvfrom() and
> recvmsg() family deal with changing IPs? IKE and DNS servers already
> use this to listen on ANY and reply to the address of the received
> packet.
>
> This is a lot of specification and code and possible interop problems
> for a use case of "saving a few bytes on some UDP packets".
>
> It is possible further discussion might convince me otherwise, although
> not likely. I'm happy to discuss this item further as a working group
> if adoption now means we can still decide it is not a good idea later.
> If adoption to the WG now means we must end up with some kind of spec,
> than I would rather not see adoption now.
>
> Paul
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>



-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

--047d7b4508a8e0de9f0502f67327
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div>Hi Paul, <br><br></div><div>Thank=
 you for raising the questions, that gives me he opportunity to clarify wha=
t have been discussed/agreed in Toronto. <br><br>As an author I am supporti=
ng the adoption of the document as a WG document. <br><br></div>In the Toro=
nto meeting, we agreed that MOBIKE versionning must be removed in the next =
version of the draft. We also agreed that Security Consideration should dis=
cuss more in detail the exposure of the IP addresses. All these will be par=
t of the next version.<br><br>The next version of the draft will define how=
 MOBIKE and the USE_TRANSPORT_MODE Notify Payload work together. As a resul=
t, they will be no MOBIKE versions, the spec will be much simpler, and we w=
ill still be fully interoperable / compatible with existing code of MOBIKE =
-- i.e. code that has not been updated. <br><br>From RFC5996 section 1.3.1,=
 the default IPsec mode is the Tunnel mode. When a USE_TRANSPORT_MODE Notif=
y Payload is received. &quot;It requests that the Child SA use transport mo=
de rather than tunnel mode
   for the SA created.  If the request is accepted, the response MUST
   also include a notification of type USE_TRANSPORT_MODE.  If the
   responder declines the request, the Child SA will be established in
   tunnel mode. &quot;<br><br></div>As a result, currently, when one receiv=
es USE_TRANSPORT_MODE and MOBIKE_SUPPORTED, it has to chose between support=
ing MOBIKE or the transport mode. The next version of the draft, will make =
possible to respond USE_TRANSPORT_MODE and MOBIKE_SUPPORTED. In all other c=
ases, nothing is changed.<br><br></div>Motivations for this are UDP (mostly=
 DNS) but also GRE tunnels. In our opinion, for the DNS use case, saving by=
tes matters especially when only the responses is returned over a degraded =
link like WLAN. <br><br></div><br></div>BR, <br>Daniel<br><div><div><br><di=
v><div><div><br><div><div><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote">On Fri, Sep 12, 2014 at 8:02 PM, Paul Wouters <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:paul@nohats.ca" target=3D"_blank">paul@nohats.ca</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span clas=
s=3D"">On Fri, 12 Sep 2014, Yaron Sheffer wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
This is a call for adopting draft-mglt-ipsecme-mobikev2 as a WG document. P=
lease respond to this mail with a Yes or No and a short<br>
rationale, at latest by Friday Sep. 19.<br>
</blockquote>
<br></span>
This document confuses me.<br>
<br>
It seems section 4 to 7 are about much more than just transport mode. It<br=
>
seems to (re?)introduce versioning, non-transport notify payloads, etc.<br>
<br>
MOBIKE is about keeping your assigend address with you, making your<br>
inner IP consistent regardless of the outer IP. That makes no sense<br>
with transport mode, which is tied to your ephemeral outer address.<br>
<br>
Transport mode IPsec is terrible idea in todays NATed world. It should<br>
die, not see more use. The NAT issues are not at all mentioned in this<br>
draft. What if two clients connect to the same MOBIKE VPN server with<br>
the same internal IP of 10.1.2.3?<br>
<br>
The use case is &quot;saving a few bytes&quot;, which to me seems very weak=
.<br>
<br>
It would only work with UDP, not TCP. For UDP, doesn&#39;t recvfrom() and<b=
r>
recvmsg() family deal with changing IPs? IKE and DNS servers already<br>
use this to listen on ANY and reply to the address of the received<br>
packet.<br>
<br>
This is a lot of specification and code and possible interop problems<br>
for a use case of &quot;saving a few bytes on some UDP packets&quot;.<br>
<br>
It is possible further discussion might convince me otherwise, although<br>
not likely. I&#39;m happy to discuss this item further as a working group<b=
r>
if adoption now means we can still decide it is not a good idea later.<br>
If adoption to the WG now means we must end up with some kind of spec,<br>
than I would rather not see adoption now.<br>
<br>
Paul<br>
<br>
______________________________<u></u>_________________<br>
IPsec mailing list<br>
<a href=3D"mailto:IPsec@ietf.org" target=3D"_blank">IPsec@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/ipsec" target=3D"_blank">h=
ttps://www.ietf.org/mailman/<u></u>listinfo/ipsec</a><br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Daniel Migault<br>Orang=
e Labs -- Security<br>+33 6 70 72 69 58
</div></div></div></div></div></div></div></div></div>

--047d7b4508a8e0de9f0502f67327--


From nobody Sun Sep 14 15:51:59 2014
Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6562F1A03D0 for <ipsec@ietfa.amsl.com>; Sun, 14 Sep 2014 15:51:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.652
X-Spam-Level: 
X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id py6Bkn_jEHKR for <ipsec@ietfa.amsl.com>; Sun, 14 Sep 2014 15:51:56 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8563D1A03E1 for <ipsec@ietf.org>; Sun, 14 Sep 2014 15:51:55 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2AA0980111; Sun, 14 Sep 2014 18:51:53 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1410735113; bh=CPvag4pFBKIcDR58M/x+7nf9v0vv15jcrnQTuaNOp/4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Ot/aZ2VmKH3MA22ZDq4HFBJ4zXmNoKdkJC0dFarMqLYlGpERrxClhYabocIra6ioC xGcHywISUGjywQE9KW1VTRStMQowPq2Qv5hIQ8fnQRBx+J5bLDAV/w/xSkaXUndfyu g/QKq7MlL8HsX2/RwA6x33nHj+cGNQfGHvRkImIA=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s8EMpqF5023421; Sun, 14 Sep 2014 18:51:52 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Sun, 14 Sep 2014 18:51:52 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Daniel Migault <mglt.ietf@gmail.com>
In-Reply-To: <CADZyTkm0BpZGviYHoYOK8o3JgRBzmAgnm5W8jEoQCZ+mS+T=5w@mail.gmail.com>
Message-ID: <alpine.LFD.2.10.1409141841511.22800@bofh.nohats.ca>
References: <54131C57.2060605@gmail.com> <alpine.LFD.2.10.1409121350180.31178@bofh.nohats.ca> <CADZyTkm0BpZGviYHoYOK8o3JgRBzmAgnm5W8jEoQCZ+mS+T=5w@mail.gmail.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/NCrCn0BRQOFjBVV0yMXzqSvJhuM
Cc: ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] Call for adoption: MOBIKEv2: MOBIKE extension for Transport mode
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Sep 2014 22:51:58 -0000

On Sat, 13 Sep 2014, Daniel Migault wrote:

> In the Toronto meeting, we agreed that MOBIKE versionning must be removed in the next version of the draft. We also agreed that Security
> Consideration should discuss more in detail the exposure of the IP addresses. All these will be part of the next version.

Okay, good to know.

> As a result, currently, when one receives USE_TRANSPORT_MODE and MOBIKE_SUPPORTED, it has to chose between supporting MOBIKE or the
> transport mode.

That makes sense to me, because combining the two does not really make
sense.

> Motivations for this are UDP (mostly DNS) but also GRE tunnels. In our opinion, for the DNS use case, saving bytes matters especially
> when only the responses is returned over a degraded link like WLAN.

What kind of differences do you meassure? Is it latency? less packet
drops and retransmits?

I take it that mobike ensures the DNS response still comes in on the
correct IP, even if you have changed links. However, I would expect the
DNS answer to get lost anyway if you are switching links and have to
wait on a new IKE SA to be (re)established to re-gain an active IPsec SA
that has your 'inner' IP on it. I would expect those delays to matter
much more than shaving of a few bytes using transport mode instead
of tunnel mode.

I do need to readup on MOBIKE to further understand how one could even
use transport mode SA's for something that's clearly meant as a tunnel
mode SA. I do not understand how the outer IP is used while protecting
the mobike inner IP.

Paul


From nobody Mon Sep 15 06:33:18 2014
Return-Path: <internet-drafts@ietf.org>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCB71A0356; Mon, 15 Sep 2014 06:33:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ny999cn1D8Qu; Mon, 15 Sep 2014 06:33:15 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7041A0330; Mon, 15 Sep 2014 06:33:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.2.p6
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140915133315.31342.33601.idtracker@ietfa.amsl.com>
Date: Mon, 15 Sep 2014 06:33:15 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/wXJz_NEiY13FVTKVgwOUFmKLK8I
Cc: ipsec@ietf.org
Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-null-auth-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Sep 2014 13:33:17 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.

        Title           : The NULL Authentication Method in IKEv2 Protocol
        Author          : Valery Smyslov
	Filename        : draft-ietf-ipsecme-ikev2-null-auth-00.txt
	Pages           : 9
	Date            : 2014-09-14

Abstract:
   This document introduces the NULL Authentication Method for the IKEv2
   Protocol.  This method provides a way to omit peer authentication in
   the IKEv2.  It may be used to preserve anonymity of or in the
   situations, where no trust relationship exists between the parties.


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

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


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

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


From nobody Mon Sep 15 06:45:31 2014
Return-Path: <daniel.palomares.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9211A0BEC for <ipsec@ietfa.amsl.com>; Mon, 15 Sep 2014 06:45:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wh--ebm0BCoN for <ipsec@ietfa.amsl.com>; Mon, 15 Sep 2014 06:45:27 -0700 (PDT)
Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58141A0491 for <ipsec@ietf.org>; Mon, 15 Sep 2014 06:45:27 -0700 (PDT)
Received: by mail-ie0-f179.google.com with SMTP id rl12so4546683iec.38 for <ipsec@ietf.org>; Mon, 15 Sep 2014 06:45:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GQxmBM+U7Z+ybg77OKXuAcPE8NH1gkqZbL6+64/cJkw=; b=HvsXLi3EaOYcx0qwNSlj8ROvTwfFSFqDIYzly/mgk2HAwH/+XMebZso/+36FyFSnEo 9oCHmKNyhJl8G0Ets7/3yh/HrpjRKUq1k9EabIc5ogn2J46nxVcEsLIlD9A3sJD1L8Lk jBPNVWqJg3VQx1xflH6jIp+boL3MSlVum423t9AGGg/ahuHhBJNX+DvMBqgyR7PZ9Jnx xixadYsQHGjecljC2OX9A1OyoCL41clC5lVzrdyH8J2oeS8xzRMygsTXYrMWXjco8eFe ciq0dhYw8qXGYiCD563yKhc5qtqwgwQdw/0YVJQgD0xKSt0oP9yfeOWBoKtTSqfQ6JPq p6zQ==
MIME-Version: 1.0
X-Received: by 10.50.26.66 with SMTP id j2mr22053688igg.45.1410788726122; Mon, 15 Sep 2014 06:45:26 -0700 (PDT)
Received: by 10.50.16.177 with HTTP; Mon, 15 Sep 2014 06:45:26 -0700 (PDT)
In-Reply-To: <54131C57.2060605@gmail.com>
References: <54131C57.2060605@gmail.com>
Date: Mon, 15 Sep 2014 15:45:26 +0200
Message-ID: <CAHf5+hqAbgX7saGdpEhMSMOfzR75CwZZKOHYFAPbqhBD7W7J0Q@mail.gmail.com>
From: Daniel Palomares <daniel.palomares.ietf@gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bd75bb2dfae0505031ad868
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/7EAH4NM-ljgqP7FXUfRR01dN9ms
Cc: ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] Call for adoption: MOBIKEv2: MOBIKE extension for Transport mode
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Sep 2014 13:45:30 -0000

--047d7bd75bb2dfae0505031ad868
Content-Type: text/plain; charset=UTF-8

Hello Yaron,

As a co-author of the draft, I support adopting this draft as a WG
document.
We implemented the very first draft (the first version) that included some
other options that are now deprecated (like flags and versioning, etc).

However, with MOBIKE and USE_TRANSPORT_MODE Notify Payload, the
implementation becomes a lot simpler. IMHO, for example, within an Open
Source implementation like StrongSwan, It wouldn't take more than 30 lines
of code.

BR
Daniel Palomares

2014-09-12 18:16 GMT+02:00 Yaron Sheffer <yaronf.ietf@gmail.com>:

>  Dear working group,
>
>
> This is a call for adopting draft-mglt-ipsecme-mobikev2 as a WG document.
> Please respond to this mail with a Yes or No and a short rationale, at
> latest by Friday Sep. 19.
>
>  Thanks,
> 	Yaron
>
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>

--047d7bd75bb2dfae0505031ad868
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hello Yaron,<br><br></div>As a co-author of the =
draft, I support adopting this draft as a WG document. <br></div><div>We im=
plemented the very first draft (the first version) that included some other=
 options that are now deprecated (like flags and versioning, etc).<br><br><=
/div><div>However, with MOBIKE and USE_TRANSPORT_MODE Notify Payload, the i=
mplementation becomes a lot simpler. IMHO, for example, within an Open Sour=
ce implementation like StrongSwan, It wouldn&#39;t take more than 30 lines =
of code.<br><br></div><div>BR<br>Daniel Palomares<br></div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">2014-09-12 18:16 GMT+02:00 Yaron =
Sheffer <span dir=3D"ltr">&lt;<a href=3D"mailto:yaronf.ietf@gmail.com" targ=
et=3D"_blank">yaronf.ietf@gmail.com</a>&gt;</span>:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
 =20

   =20
   =20
 =20
  <div style=3D"direction:ltr" text=3D"#000000" bgcolor=3D"#FFFFFF">
    <pre style=3D"margin:0em">Dear working group,

</pre>
    <tt>This is a call for adopting draft-mglt-ipsecme-mobikev2 as a </tt><=
tt>WG
      document. Please respond to this mail with a Yes or No and a short
    </tt><tt>rationale, at latest by Friday Sep. 19.<br>
      <br>
    </tt>
    <pre style=3D"margin:0em">Thanks,
	Yaron

</pre>
  </div>


<br>_______________________________________________<br>
IPsec mailing list<br>
<a href=3D"mailto:IPsec@ietf.org">IPsec@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/ipsec" target=3D"_blank">h=
ttps://www.ietf.org/mailman/listinfo/ipsec</a><br>
<br></blockquote></div><br></div></div>

--047d7bd75bb2dfae0505031ad868--


From nobody Wed Sep 17 04:00:00 2014
Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94291A0109 for <ipsec@ietfa.amsl.com>; Wed, 17 Sep 2014 03:59:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItyQzhEa-tSz for <ipsec@ietfa.amsl.com>; Wed, 17 Sep 2014 03:59:57 -0700 (PDT)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C75E1A00F5 for <ipsec@ietf.org>; Wed, 17 Sep 2014 03:59:56 -0700 (PDT)
Received: by mail-la0-f48.google.com with SMTP id ty20so1572105lab.21 for <ipsec@ietf.org>; Wed, 17 Sep 2014 03:59:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=bKqRIY4xAQ/88ZHQmwKknjhh3c4z0uCpIT+hHDqbCac=; b=c7lOQ2t54ryiIE7wxlkZo1w8+KlHR7/XPs2ZeKkeEW8c1FDgRr/UIY5FpTxmGIaAv/ qzageOjb8q6+YP9AQnjVAf03/tYb4VYfL+W3gB03PIDh0VmeGe4Pavh/d5oUeAUrkmmW 59KRJEoyjXmvTrEdoLzU2OVB3ZyUFZVKPInLXZe4lYUp6Bgu0U/G3Niy2QP4EI1hmxy5 TioUdV/uU/3XY4Lnf1/R3U+ECIrf1xkaTLWda7wqdMtcFuUOCO2wekdceO1B8/1s0rgw 8r11Mgqsrag4tmS9iZHpx4I9ZlvGpumGC4tFFk48P2yyBDXuTDB6pcBfxAIk24F7Dku/ 5T6w==
X-Received: by 10.112.63.71 with SMTP id e7mr17147730lbs.89.1410951595444; Wed, 17 Sep 2014 03:59:55 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id k8sm5824573laf.5.2014.09.17.03.59.53 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 17 Sep 2014 03:59:54 -0700 (PDT)
Message-ID: <4A81BADF09C04D50BFA83D59711A0EF7@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Tero Kivinen" <kivinen@iki.fi>
References: <F68C660364DABE41AF4617F517EF548411707BE2@ESESSMB309.ericsson.se><21493.55390.157248.181030@fireball.kivinen.iki.fi><C949D5C9077942ACA31105FE4156154E@buildpc> <21504.31762.454252.961126@fireball.kivinen.iki.fi> <DC2FED9C253548E5875C4E5CCCFD40D0@buildpc>
Date: Wed, 17 Sep 2014 15:00:00 +0400
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/n_XVfpy1aXTrqVBb5PbRawcoU10
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Typos in draft-kivinen-ipsecme-ikev2-rfc5996bis-04
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Sep 2014 10:59:59 -0000

In Section 3.8 (Authentication Payload) the description
of the 3-octet RESERVED field is absent. I think it is a typo,
as in all other cases, when reserved field is present
in payload (KE, ID, TS, CP), its description is given.


From nobody Wed Sep 17 15:52:57 2014
Return-Path: <touch@isi.edu>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD741A0AF6 for <ipsec@ietfa.amsl.com>; Wed, 17 Sep 2014 15:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.852
X-Spam-Level: 
X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4Kp6X5Nnzd0 for <ipsec@ietfa.amsl.com>; Wed, 17 Sep 2014 15:52:52 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F3C1A04E8 for <ipsec@ietf.org>; Wed, 17 Sep 2014 15:52:52 -0700 (PDT)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s8HMqFGp023915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 Sep 2014 15:52:15 -0700 (PDT)
Message-ID: <541A109E.1070405@isi.edu>
Date: Wed, 17 Sep 2014 15:52:14 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: Paul Wouters <paul@nohats.ca>, Yaron Sheffer <yaronf.ietf@gmail.com>
References: <54131C57.2060605@gmail.com> <alpine.LFD.2.10.1409121350180.31178@bofh.nohats.ca>
In-Reply-To: <alpine.LFD.2.10.1409121350180.31178@bofh.nohats.ca>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Gr50_3OhiXMbc1OadrWc9vYb80U
Cc: ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] Call for adoption: MOBIKEv2: MOBIKE extension for Transport mode
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Sep 2014 22:52:54 -0000

On 9/12/2014 11:02 AM, Paul Wouters wrote:
> On Fri, 12 Sep 2014, Yaron Sheffer wrote:
> 
>> This is a call for adopting draft-mglt-ipsecme-mobikev2 as a WG
>> document. Please respond to this mail with a Yes or No and a short
>> rationale, at latest by Friday Sep. 19.
> 
> This document confuses me.
> 
> It seems section 4 to 7 are about much more than just transport mode. It
> seems to (re?)introduce versioning, non-transport notify payloads, etc.
> 
> MOBIKE is about keeping your assigend address with you, making your
> inner IP consistent regardless of the outer IP. That makes no sense
> with transport mode, which is tied to your ephemeral outer address.
> 
> Transport mode IPsec is terrible idea in todays NATed world. It should
> die, not see more use. 

See RFC 3884. Just because you're getting rid of IPsec-controlled
tunnels doesn't mean you have to give up tunnels, and using separate
IP-in-IP tunneling has distinct advantages in today's dynamic routed,
virtual networked world.

If you want to pick something to die, please kill IPsec tunnel mode as
an integrated beast.

Joe


From nobody Thu Sep 18 04:42:21 2014
Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20C01A873D for <ipsec@ietfa.amsl.com>; Thu, 18 Sep 2014 04:42:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9UIxsVYcxiD for <ipsec@ietfa.amsl.com>; Thu, 18 Sep 2014 04:42:17 -0700 (PDT)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FB671A0166 for <ipsec@ietf.org>; Thu, 18 Sep 2014 04:42:17 -0700 (PDT)
Received: by mail-la0-f46.google.com with SMTP id q1so375280lam.19 for <ipsec@ietf.org>; Thu, 18 Sep 2014 04:42:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=DUrwbZ5fQnGyzdHnG2/J2cXxXx+5bJrhNDpmpkTfdf8=; b=jLXhGf3rroUvmqEODia+ntrsRoPa02oK6UeY3pS0uGQtKBE6E9KESYH7AxqTpP08O9 W5kz5xRIgHSa+KjBsFEUv6pWLzT9aMpV6LBaN8zKzOerQz4HcrjdD3Acql+vLpbbY3MB EVH9+hLt3+Db3UGIwqcWJgDYB6eNJr22ECXa1brUY20z3rMHl5PGKyybMeY7z6kqPIv+ lGm3oV7FvKLlw0klWPFf0m8SKcRsafPnwb/FF45wBfZz8WbDLphjfiQTRy+Q6vBF0/4F Cb0wsMfywHPzAfS8jNxPgCMh+gQsstC60ulNtSEzwQhSAiBYTWZq2b+8FkOts3LG2VwA jvOQ==
X-Received: by 10.112.76.230 with SMTP id n6mr3820042lbw.8.1411040535600; Thu, 18 Sep 2014 04:42:15 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id i3sm6826494laa.8.2014.09.18.04.42.13 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Sep 2014 04:42:14 -0700 (PDT)
Message-ID: <EAFA100B50B24E0D81E9BCA44CAE9D94@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Tero Kivinen" <kivinen@iki.fi>
References: <F68C660364DABE41AF4617F517EF548411707BE2@ESESSMB309.ericsson.se><21493.55390.157248.181030@fireball.kivinen.iki.fi><C949D5C9077942ACA31105FE4156154E@buildpc> <21504.31762.454252.961126@fireball.kivinen.iki.fi> <DC2FED9C253548E5875C4E5CCCFD40D0@buildpc> <4A81BADF09C04D50BFA83D59711A0EF7@buildpc>
Date: Thu, 18 Sep 2014 15:42:47 +0400
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/AFZTIkGoNn0PEYv7RSDwplkdLS8
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Typos in draft-kivinen-ipsecme-ikev2-rfc5996bis-04
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Sep 2014 11:42:18 -0000

In Section 3.13.1 the description of the Selector Length field
doesn't mention that it is unsigned integer (as it is mentioned
for all other such fields).


From nobody Thu Sep 18 06:27:17 2014
Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5311A02D5 for <ipsec@ietfa.amsl.com>; Thu, 18 Sep 2014 06:27:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.652
X-Spam-Level: 
X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yob5c0bZm_9K for <ipsec@ietfa.amsl.com>; Thu, 18 Sep 2014 06:27:15 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00A51A038C for <ipsec@ietf.org>; Thu, 18 Sep 2014 06:27:15 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1666080416; Thu, 18 Sep 2014 09:27:14 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1411046834; bh=+OiIF1EqDtLTV94KU1H6RZgFOte3TrVjOyfe0lpldTk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=D2HhOWsMIKU7up83d7GRNxzaeVjolzx+XVya19Jb4rohupyUDJb7e1eyaKSLFfsow jDGe6zyyWgeiAKnPzIdZnvRvZijc6ekI+a4lUmvc57qz/HfTzHA0diVGXvt/mBWFpF +cXYnFLD5sHanJrLdVqxiOf2uv6toumt/YuVhf50=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s8IDRCFb015920; Thu, 18 Sep 2014 09:27:13 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Thu, 18 Sep 2014 09:27:12 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Valery Smyslov <svanru@gmail.com>
In-Reply-To: <EAFA100B50B24E0D81E9BCA44CAE9D94@buildpc>
Message-ID: <alpine.LFD.2.10.1409180926200.1198@bofh.nohats.ca>
References: <F68C660364DABE41AF4617F517EF548411707BE2@ESESSMB309.ericsson.se><21493.55390.157248.181030@fireball.kivinen.iki.fi><C949D5C9077942ACA31105FE4156154E@buildpc> <21504.31762.454252.961126@fireball.kivinen.iki.fi> <DC2FED9C253548E5875C4E5CCCFD40D0@buildpc> <4A81BADF09C04D50BFA83D59711A0EF7@buildpc> <EAFA100B50B24E0D81E9BCA44CAE9D94@buildpc>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/afgv-TWLI2znKq8QqjGkDz6IDRo
Cc: ipsec@ietf.org, Tero Kivinen <kivinen@iki.fi>
Subject: Re: [IPsec] Typos in draft-kivinen-ipsecme-ikev2-rfc5996bis-04
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Sep 2014 13:27:17 -0000

On Thu, 18 Sep 2014, Valery Smyslov wrote:

> In Section 3.13.1 the description of the Selector Length field
> doesn't mention that it is unsigned integer (as it is mentioned
> for all other such fields).

What's an unsigned integer? :P

Do we mean octets? :)

Paul


From nobody Thu Sep 18 06:55:35 2014
Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161EB1A87DF for <ipsec@ietfa.amsl.com>; Thu, 18 Sep 2014 06:55:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEJxk96pnQB9 for <ipsec@ietfa.amsl.com>; Thu, 18 Sep 2014 06:55:30 -0700 (PDT)
Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EBBB1A87D4 for <ipsec@ietf.org>; Thu, 18 Sep 2014 06:55:30 -0700 (PDT)
Received: by mail-lb0-f173.google.com with SMTP id w7so1188505lbi.32 for <ipsec@ietf.org>; Thu, 18 Sep 2014 06:55:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=t1fOfRnigOsDK9UM1OmtY45c8gI/o/NOB7R2oe4L7HE=; b=0GanECXxMrRiT0cI8YTsHnK+z2x/2UHhoYdETFoIF2oXSMeSedpoG/yfAsvdnO5tuk qly6/cWqy46Vmiw/lTOtGe0nVCQ00XlHPJ5t4XvzJmawA5wBf1SkXznOlOrKmhs8AVN4 pXfFibx/iiZAvjc8+fM+7PYLylRhTct8qOGJBvkHtJWozZ7L4ryUCcee785WgUf24rMh Kk4Y5oIvJ5KE5g4fQHUwxzyWCHjb+x1qMepvorT4kMZvpIoqCLS0PLB9QlQBdXJj4iC8 WvgKVHfnrRcZS2K8ytiDiiVowwA5JuwVRa7NrzP588ocJnL0nXLcO6ZFtZu7zHqXM7Vs QB7w==
X-Received: by 10.153.11.132 with SMTP id ei4mr4902lad.24.1411048528563; Thu, 18 Sep 2014 06:55:28 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id h6sm6273659lag.21.2014.09.18.06.55.27 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Sep 2014 06:55:27 -0700 (PDT)
Message-ID: <EE25ACA922BC4A70852C7BD495162228@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Paul Wouters" <paul@nohats.ca>
References: <F68C660364DABE41AF4617F517EF548411707BE2@ESESSMB309.ericsson.se><21493.55390.157248.181030@fireball.kivinen.iki.fi><C949D5C9077942ACA31105FE4156154E@buildpc> <21504.31762.454252.961126@fireball.kivinen.iki.fi> <DC2FED9C253548E5875C4E5CCCFD40D0@buildpc> <4A81BADF09C04D50BFA83D59711A0EF7@buildpc> <EAFA100B50B24E0D81E9BCA44CAE9D94@buildpc> <alpine.LFD.2.10.1409180926200.1198@bofh.nohats.ca>
Date: Thu, 18 Sep 2014 17:56:01 +0400
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/IzHMmDDfVG_qO0KBXiyj8_CNYMA
Cc: ipsec@ietf.org, Tero Kivinen <kivinen@iki.fi>
Subject: Re: [IPsec] Typos in draft-kivinen-ipsecme-ikev2-rfc5996bis-04
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Sep 2014 13:55:32 -0000

>> In Section 3.13.1 the description of the Selector Length field
>> doesn't mention that it is unsigned integer (as it is mentioned
>> for all other such fields).
>
> What's an unsigned integer? :P
> Do we mean octets? :)

Unsigned integer is an interpretation of this two-octets value
(presumably in network byte order). It is explicitely stated
for most multi-byte fields in the document. For example:

Section 3.11 (Delete Payload):

   o  Num of SPIs (2 octets, unsigned integer) - The number of SPIs
      contained in the Delete payload.  The size of each SPI is defined
      by the SPI Size field.

Compare with the Section 3.13.1, which I has complained about:

   o  Selector Length - Specifies the length of this Traffic Selector
      substructure including the header.

No indication of how "Selector Length" (it is 2 octets) should be treated.

OK, we all know how to interpret it (and we have interoperable 
implementations),
but it needs to be stated here, as it is stated for other such fields
in the document. I'm probably acting here as a perisher, but as
document is intended to become Internet Standard such nits need to be
removed, IMHO.

Regards,
Valery.

> Paul


From nobody Thu Sep 18 07:10:34 2014
Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605621A87DF for <ipsec@ietfa.amsl.com>; Thu, 18 Sep 2014 07:10:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.652
X-Spam-Level: 
X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.652] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LweqlrzYqW5k for <ipsec@ietfa.amsl.com>; Thu, 18 Sep 2014 07:10:31 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F18D51A0BEB for <ipsec@ietf.org>; Thu, 18 Sep 2014 07:10:30 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 32B0080416; Thu, 18 Sep 2014 10:10:30 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1411049430; bh=acUR20+1gpQYCQbqzORgad5uisl+h9yeKZEJcp4gZqM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KbistGRfON0DoTiTWRKavnlKjTToqdPkwM1Q/2t9kiOrSpknbr2wskb7dSagx54uI DhooeBaPDTohXl3pEPiOr0yhmM//4RDdtDn62aKfY2LLCs8M4aLFzkUG2Ga+UM847L JqYQIrUQ5CbK0ZCMDb9t/rKv0cYI4G0DmeFzvcdw=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s8IEATQR017908; Thu, 18 Sep 2014 10:10:29 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Thu, 18 Sep 2014 10:10:29 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Valery Smyslov <svanru@gmail.com>
In-Reply-To: <EE25ACA922BC4A70852C7BD495162228@buildpc>
Message-ID: <alpine.LFD.2.10.1409181008590.1198@bofh.nohats.ca>
References: <F68C660364DABE41AF4617F517EF548411707BE2@ESESSMB309.ericsson.se><21493.55390.157248.181030@fireball.kivinen.iki.fi><C949D5C9077942ACA31105FE4156154E@buildpc> <21504.31762.454252.961126@fireball.kivinen.iki.fi> <DC2FED9C253548E5875C4E5CCCFD40D0@buildpc> <4A81BADF09C04D50BFA83D59711A0EF7@buildpc> <EAFA100B50B24E0D81E9BCA44CAE9D94@buildpc> <alpine.LFD.2.10.1409180926200.1198@bofh.nohats.ca> <EE25ACA922BC4A70852C7BD495162228@buildpc>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/YEGP3kssPXNGVs1DHeqnahOaELE
Cc: "ipsec@ietf.org WG" <ipsec@ietf.org>
Subject: Re: [IPsec] Typos in draft-kivinen-ipsecme-ikev2-rfc5996bis-04
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Sep 2014 14:10:32 -0000

On Thu, 18 Sep 2014, Valery Smyslov wrote:

>> What's an unsigned integer? :P
>> Do we mean octets? :)
>
> Unsigned integer is an interpretation of this two-octets value
> (presumably in network byte order). It is explicitely stated
> for most multi-byte fields in the document. For example:
>
> Section 3.11 (Delete Payload):
>
>  o  Num of SPIs (2 octets, unsigned integer) - The number of SPIs
>     contained in the Delete payload.  The size of each SPI is defined
>     by the SPI Size field.
>
> Compare with the Section 3.13.1, which I has complained about:
>
>  o  Selector Length - Specifies the length of this Traffic Selector
>     substructure including the header.
>
> No indication of how "Selector Length" (it is 2 octets) should be treated.
>
> OK, we all know how to interpret it (and we have interoperable 
> implementations),
> but it needs to be stated here, as it is stated for other such fields
> in the document. I'm probably acting here as a perisher, but as
> document is intended to become Internet Standard such nits need to be
> removed, IMHO.

Oh, I agree completely! Had I been able to pay more attention at the
time, I would have suggested never to mention "integers" or "(un)signed"
at all, and only mentioned octets. But we should make it all consistent
in the document, so thanks for catching that!

Paul


From nobody Thu Sep 18 07:23:41 2014
Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3957D1A01CB for <ipsec@ietfa.amsl.com>; Thu, 18 Sep 2014 07:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8K6q1vh_2Pa for <ipsec@ietfa.amsl.com>; Thu, 18 Sep 2014 07:23:37 -0700 (PDT)
Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B461A0379 for <ipsec@ietf.org>; Thu, 18 Sep 2014 07:23:37 -0700 (PDT)
Received: by mail-lb0-f173.google.com with SMTP id w7so1237890lbi.4 for <ipsec@ietf.org>; Thu, 18 Sep 2014 07:23:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:from:to:references:subject:date:mime-version :content-type; bh=Cj5q3gE8sJedeEVE/zNpimSQl2UTXUDdOYSMSMDXQxQ=; b=So87jC4eRrBki5yvrrS7monaHTNWIzpJW7oY+CFKv0vPBhwu8YFO+BOUqzOKaEn6q5 hoqnghxAxQzcqfr9RIkXPWJ842bydtOcDY2nIXRIdWGkpTlsXAS2GCpEraCKsLJdRA5G IyUKkIdk8lnSayTxXSxQlsJgSB0pHPjdS8J4hOYPF857QOXZKKpKg6usLNML83rXgcoS CogkftL36xRVY4RbhSRtOXKuPhY2PEoFXBLXGBXT3X7/XeyTuiGtR3Fd/IgDpbFh2ybY MDZmiC6czKpCoCZxUpTFqPyEeJ/rljlD8iv53JXbJEUSHQxq6zHr69WzpCL2rZsxcbVY tqPg==
X-Received: by 10.152.36.134 with SMTP id q6mr5255767laj.35.1411050215407; Thu, 18 Sep 2014 07:23:35 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id xy9sm7200395lbb.6.2014.09.18.07.23.32 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 18 Sep 2014 07:23:33 -0700 (PDT)
Message-ID: <5286AA7487B04896BA171C6739551FAD@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Yaron Sheffer" <yaronf.ietf@gmail.com>, "ipsec" <ipsec@ietf.org>
References: <54131C57.2060605@gmail.com>
Date: Thu, 18 Sep 2014 18:24:07 +0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0627_01CFD36D.BBF97EA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/qbVVbbC9PVFKxqR3wVA0qljth6w
Subject: Re: [IPsec] Call for adoption: MOBIKEv2: MOBIKE extension for Transportmode
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Sep 2014 14:23:39 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0627_01CFD36D.BBF97EA0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Yaron,

I think that the draft in its original form doesn't exist now (btw, it =
seemes to have expired),
as the authors has clearly indicated, that the solution, that was =
presented
in the draft, is no longer actual, and a new, more simple approach =
should be taken.
But it is described in no draft yet. Unless we are adopting the problem, =
and not
the proposed solution, I think it is better to postpone the adoption =
untill
the new draft describing the new solution is published.

Regards,
Valery.


  ----- Original Message -----=20
  From: Yaron Sheffer=20
  To: ipsec=20
  Sent: Friday, September 12, 2014 8:16 PM
  Subject: [IPsec] Call for adoption: MOBIKEv2: MOBIKE extension for =
Transportmode


Dear working group,

This is a call for adopting draft-mglt-ipsecme-mobikev2 as a WG =
document. Please respond to this mail with a Yes or No and a short =
rationale, at latest by Friday Sep. 19.


Thanks,
	Yaron



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


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

------=_NextPart_000_0627_01CFD36D.BBF97EA0
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML style=3D"DIRECTION: ltr"><HEAD>
<META content=3D"text/html; charset=3Dutf-8" http-equiv=3Dcontent-type>
<STYLE type=3Dtext/css>BODY P {
	MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm
}
</STYLE>

<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.23588"></HEAD>
<BODY style=3D"DIRECTION: ltr" bgColor=3D#ffffff text=3D#000000=20
bidimailui-charset-is-forced=3D"true">
<DIV><FONT size=3D2>Hi Yaron,</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>I think that the draft in its&nbsp;original form =
doesn't exist=20
now (btw, it seemes to have expired),</FONT></DIV>
<DIV><FONT size=3D2>as the authors has clearly indicated, that the =
solution, that=20
was presented</FONT></DIV>
<DIV><FONT size=3D2>in the draft, is no longer actual, and a new, more =
simple=20
approach should be taken.</FONT></DIV>
<DIV><FONT size=3D2>But it is described&nbsp;in no draft&nbsp;yet. =
Unless we are=20
adopting the problem, and not</FONT></DIV>
<DIV><FONT size=3D2>the proposed solution, I think it is better to =
postpone the=20
adoption untill</FONT></DIV>
<DIV><FONT size=3D2>the&nbsp;new draft describing the new solution is=20
published.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Regards,</FONT></DIV>
<DIV><FONT size=3D2>Valery.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; =
PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"FONT: 10pt arial; BACKGROUND: #e4e4e4; font-color: =
black"><B>From:</B>=20
  <A title=3Dyaronf.ietf@gmail.com =
href=3D"mailto:yaronf.ietf@gmail.com">Yaron=20
  Sheffer</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A title=3Dipsec@ietf.org=20
  href=3D"mailto:ipsec@ietf.org">ipsec</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, September 12, =
2014 8:16=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [IPsec] Call for =
adoption:=20
  MOBIKEv2: MOBIKE extension for Transportmode</DIV>
  <DIV><BR></DIV><PRE style=3D"MARGIN: 0em">Dear working group,

</PRE><TT>This is a call for adopting draft-mglt-ipsecme-mobikev2 as a=20
  </TT><TT>WG document. Please respond to this mail with a Yes or No and =
a short=20
  </TT><TT>rationale, at latest by Friday Sep. 19.<BR><BR></TT><PRE =
style=3D"MARGIN: 0em">Thanks,
	Yaron

</PRE>
  <P>
  <HR>

  <P></P>_______________________________________________<BR>IPsec =
mailing=20
  list<BR><A href=3D"mailto:IPsec@ietf.org">IPsec@ietf.org</A><BR><A=20
  =
href=3D"https://www.ietf.org/mailman/listinfo/ipsec">https://www.ietf.org=
/mailman/listinfo/ipsec</A><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0627_01CFD36D.BBF97EA0--


From nobody Thu Sep 18 17:19:30 2014
Return-Path: <fdetienn@cisco.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3201A9109 for <ipsec@ietfa.amsl.com>; Thu, 18 Sep 2014 17:19:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.153
X-Spam-Level: 
X-Spam-Status: No, score=-16.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mOuy1o3XI9X for <ipsec@ietfa.amsl.com>; Thu, 18 Sep 2014 17:19:22 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69721A910B for <ipsec@ietf.org>; Thu, 18 Sep 2014 17:19:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=970; q=dns/txt; s=iport; t=1411085959; x=1412295559; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sfHw6aQq5mMjY9vC1S8v4jvMcUZvMUbkSzx9ZzC+soY=; b=m9E2UjiI0qTGvSBRXh1zZumPUgofYUnvC1SQ682qUVaWF3EOgor4CsLw vYDsxIenbpQSqkfZtTvAJ3bcoLtDw//ZO7uU8ksSJPTc5lFLDOus1l+Kp n+hWgNFrNmNfSVNu7JjzwdfXeYUqW2qwf1wWh+koxox0j1e+xPHk8B1X8 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FAIx1G1StJV2P/2dsb2JhbABggw1TVwTJPwqHTQGBChYBeYQEAQEDAQEBARpRCwULAgEIRiEGCyUCBA4FiCoDCQgNun4Nhy4BEwSNSoFcAQEcMweDLoEdBZFOiS6CEI8GhkKDXmyBDzmBAgEBAQ
X-IronPort-AV: E=Sophos;i="5.04,550,1406592000"; d="scan'208";a="79286371"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP; 19 Sep 2014 00:19:19 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s8J0JJOJ028687 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Sep 2014 00:19:19 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Thu, 18 Sep 2014 19:19:18 -0500
From: "Frederic Detienne (fdetienn)" <fdetienn@cisco.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Thread-Topic: [IPsec] Call for adoption: MOBIKEv2: MOBIKE extension for Transport	mode
Thread-Index: AQHPzqT0URE9vbfrOUeGsYI2zD11hJwH9TkA
Date: Fri, 19 Sep 2014 00:19:18 +0000
Message-ID: <5FC503C4-B291-4CA9-BC52-B6A4482BAFD6@cisco.com>
References: <54131C57.2060605@gmail.com>
In-Reply-To: <54131C57.2060605@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.154.67.0]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <D98B6813FC5B134F82963D0106CC1A1F@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/5mHgyeBln9DJxVLGvk5JZVfM37I
Cc: ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] Call for adoption: MOBIKEv2: MOBIKE extension for Transport	mode
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Sep 2014 00:19:24 -0000

Answer: yes, should pursue

Transport mode is an important use case.

I concur with Joe Touch=92s arguments on Tunnel Mode. There are much more p=
owerful overlay methods than IPsec Tunnel mode yet IPsec/IKE security is th=
e best in its class. In this area, transport mode and is needed.

For native applications, tunnel mode simply adds unnecessary burden and ove=
rhead.

MOBIKE for transport mode is relevant and useful even if transport mode is =
misunderstood.

thanks,

	fred

On 12 Sep 2014, at 09:16, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

> Dear working group,
>=20
>=20
> This is a call for adopting draft-mglt-ipsecme-mobikev2 as a WG document.=
 Please respond to this mail with a Yes or No and a short rationale, at lat=
est by Friday Sep. 19.
>=20
> Thanks,
> 	Yaron
>=20
>=20
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec


From nobody Fri Sep 19 02:41:11 2014
Return-Path: <manishkr@cisco.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5175B1A006B for <ipsec@ietfa.amsl.com>; Fri, 19 Sep 2014 02:41:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.153
X-Spam-Level: 
X-Spam-Status: No, score=-16.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-ocol4e0FPl for <ipsec@ietfa.amsl.com>; Fri, 19 Sep 2014 02:41:08 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7BC71A0068 for <ipsec@ietf.org>; Fri, 19 Sep 2014 02:41:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2333; q=dns/txt; s=iport; t=1411119667; x=1412329267; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/8QPbaTZXSCepl3l65KMBkUOGqAxsK7ktEPB1Qm7G9A=; b=KElMiaTQENtvNvyKE0mWfrwNAqoTRt91yMRgXRpn0v1nmOhCLT2TQvfp dQzn66vjOqHNwFqdsMGM4ji0RxSlMtazkzUB294mhGpMSjszjRrIdO7XL k5FC9I0MrOGVWGqhsebl260vjuAy5icLrHZbV0bQ32JPAjT/d9rOLAqkE c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFAEf5G1StJA2E/2dsb2JhbABggw1TVwTJVAqHTQGBAhYBeYQEAQEEAQEBGh00CxACAQgYHhAnCyUCBAENBYg+DcJcARMEjyYBAU8HhEsFkU6LPpVIgWcIFoFZbIEPOYECAQEB
X-IronPort-AV: E=Sophos;i="5.04,554,1406592000"; d="scan'208";a="356492555"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP; 19 Sep 2014 09:41:07 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8J9f7sg027364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Sep 2014 09:41:07 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.163]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Fri, 19 Sep 2014 04:41:06 -0500
From: "Manish Kumar (manishkr)" <manishkr@cisco.com>
To: Paul Wouters <paul@nohats.ca>, Yaron Sheffer <yaronf.ietf@gmail.com>
Thread-Topic: [IPsec] Call for adoption: MOBIKEv2: MOBIKE extension for Transport mode
Thread-Index: AQHPzrPWRLwerj0eMEKLxt9Gpu/v4JwI7j2A
Date: Fri, 19 Sep 2014 09:41:06 +0000
Message-ID: <D041F68C.27F1D%manishkr@cisco.com>
References: <54131C57.2060605@gmail.com> <alpine.LFD.2.10.1409121350180.31178@bofh.nohats.ca>
In-Reply-To: <alpine.LFD.2.10.1409121350180.31178@bofh.nohats.ca>
Accept-Language: en-IN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.1.140326
x-originating-ip: [10.65.72.98]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <AD788B69AECA2E4F89505824DEC2146E@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/ZSSBsKpzmESmlXoMHqX87Sk4bWc
Cc: ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] Call for adoption: MOBIKEv2: MOBIKE extension for Transport mode
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Sep 2014 09:41:09 -0000

While I have not had a chance to go through the draft to comment on the
contents but I would definitely vote for the value in the use case. Usage
of transport mode doesn't mean no tunnelling; just simply, using a
tunnelling method more appropriate for the usage. I would rather be in
favour of decoupling tunnelling part from IPSec (any appropriate
tunnelling method) so that IPSec is more relevant for wider used cases and
vice-versa.

Thanks,
Manish

On 12/09/14 11:32 PM, "Paul Wouters" <paul@nohats.ca> wrote:

>On Fri, 12 Sep 2014, Yaron Sheffer wrote:
>
>> This is a call for adopting draft-mglt-ipsecme-mobikev2 as a WG
>>document. Please respond to this mail with a Yes or No and a short
>> rationale, at latest by Friday Sep. 19.
>
>This document confuses me.
>
>It seems section 4 to 7 are about much more than just transport mode. It
>seems to (re?)introduce versioning, non-transport notify payloads, etc.
>
>MOBIKE is about keeping your assigend address with you, making your
>inner IP consistent regardless of the outer IP. That makes no sense
>with transport mode, which is tied to your ephemeral outer address.
>
>Transport mode IPsec is terrible idea in todays NATed world. It should
>die, not see more use. The NAT issues are not at all mentioned in this
>draft. What if two clients connect to the same MOBIKE VPN server with
>the same internal IP of 10.1.2.3?
>
>The use case is "saving a few bytes", which to me seems very weak.
>
>It would only work with UDP, not TCP. For UDP, doesn't recvfrom() and
>recvmsg() family deal with changing IPs? IKE and DNS servers already
>use this to listen on ANY and reply to the address of the received
>packet.
>
>This is a lot of specification and code and possible interop problems
>for a use case of "saving a few bytes on some UDP packets".
>
>It is possible further discussion might convince me otherwise, although
>not likely. I'm happy to discuss this item further as a working group
>if adoption now means we can still decide it is not a good idea later.
>If adoption to the WG now means we must end up with some kind of spec,
>than I would rather not see adoption now.
>
>Paul
>
>_______________________________________________
>IPsec mailing list
>IPsec@ietf.org
>https://www.ietf.org/mailman/listinfo/ipsec


From nobody Fri Sep 19 07:39:36 2014
Return-Path: <k.pentikousis@eict.de>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAD41A01F3; Fri, 19 Sep 2014 07:39:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.902
X-Spam-Level: 
X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ssLLwaljCdE; Fri, 19 Sep 2014 07:39:32 -0700 (PDT)
Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD071A01D2; Fri, 19 Sep 2014 07:39:32 -0700 (PDT)
Received: by mx2.eict.de (Postfix, from userid 481) id 31C941FF55; Fri, 19 Sep 2014 16:39:31 +0200 (CEST)
Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id D0C871FF4F; Fri, 19 Sep 2014 16:39:30 +0200 (CEST)
Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 748783782F8; Fri, 19 Sep 2014 16:39:30 +0200 (CEST)
Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Fri, 19 Sep 2014 16:39:30 +0200
From: Kostas Pentikousis <k.pentikousis@eict.de>
To: "ippm@ietf.org" <ippm@ietf.org>
Date: Fri, 19 Sep 2014 16:39:29 +0200
Thread-Topic: draft-ietf-ippm-ipsec-05
Thread-Index: Ac/UFvktbPjuG6fGTH+28LXEBf6i3AAAAtoQ
Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C72A98A@SBS2008.eict.local>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/sSTYz7IU_Rk6kXms_t_lQMfDGuE
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: [IPsec] draft-ietf-ippm-ipsec-05
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Sep 2014 14:39:34 -0000

RGVhciBhbGwgYXQgaXBwbSBhbmQgaXBzZWMsDQoNCldlIGhhdmUgdXBkYXRlZCBkcmFmdC1pZXRm
LWlwcG0taXBzZWMgYmFzZWQgb24gdGhlIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyB3ZSByZWNl
aXZlZCBhdCB0aGUgV0dMQyBhcyB3ZWxsIGFzIHRoZSBkaXNjdXNzaW9uIGluIFRvcm9udG8uDQoN
ClBsZWFzZSBraW5kbHkgaGF2ZSBhIGxvb2sgKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv
ZG9jL2RyYWZ0LWlldGYtaXBwbS1pcHNlYy8pIGFuZCBsZXQgdXMga25vdyBhbnkgZnVydGhlciBj
b21tZW50cyBvciBzdWdnZXN0aW9ucy4NCg0KQmVzdCByZWdhcmRzLA0KDQpLb3N0YXMNCg==


From nobody Fri Sep 19 15:21:35 2014
Return-Path: <ietf-ipr@ietf.org>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1470D1A8901; Fri, 19 Sep 2014 15:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8B_9gLxtIFsD; Fri, 19 Sep 2014 15:21:31 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 685B01A88F4; Fri, 19 Sep 2014 15:21:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Secretariat <ietf-ipr@ietf.org>
To: kseo@bbn.com,kent@bbn.com
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140919222130.26859.10088.idtracker@ietfa.amsl.com>
Date: Fri, 19 Sep 2014 15:21:30 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/DGmQk8zyqAypqwW1uGo6FkpHdSI
Cc: byfraser@cisco.com, ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com, tytso@mit.edu, ipr-announce@ietf.org, stephen.farrell@cs.tcd.ie
Subject: [IPsec] IPR Disclosure: SSH Communications Security Oyj's Statement about IPR related to RFC 4301
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Sep 2014 22:21:32 -0000

Dear Karen Seo, Dr. Stephen T. Kent:

 An IPR disclosure that pertains to your RFC entitled "Security Architecture for
the Internet Protocol" (RFC4301) was submitted to the IETF Secretariat on
2014-09-19 and has been posted on the "IETF Page of Intellectual Property Rights
Disclosures" (https://datatracker.ietf.org/ipr/2435/). The title of the IPR
disclosure is "SSH Communications Security Oyj's Statement about IPR related to
RFC 4301."");

The IETF Secretariat


From nobody Sun Sep 21 12:47:42 2014
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC191A01F4 for <ipsec@ietfa.amsl.com>; Sun, 21 Sep 2014 12:47:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.006
X-Spam-Level: *
X-Spam-Status: No, score=1.006 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.105, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id excVc32P-8oT for <ipsec@ietfa.amsl.com>; Sun, 21 Sep 2014 12:47:40 -0700 (PDT)
Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D057A1A01E1 for <ipsec@ietf.org>; Sun, 21 Sep 2014 12:47:39 -0700 (PDT)
Received: by mail-we0-f180.google.com with SMTP id u56so1930333wes.11 for <ipsec@ietf.org>; Sun, 21 Sep 2014 12:47:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=i7NUO1SLvg25IBOQkLczP+OiJMF7oAZtV3w7oNpX6ac=; b=DQXEPTwEbfbsYGZEOUrF5GiWs8fVT/EBsqpMhVx5nRot13EhGECyOUkLDN8eSTpBDg 4Ycy+W5CRnozuNy+NhFNkQkXTCBFivu0C0X/UCCBEYMLUy3Czncelx4cI1Hb/ysii/q3 U/MNd7I5ws0nBEmMkwnUpjlDcEzHcjavtUyilwL68eoRM82cvQid0lMVDj702RTAB5Vk LQ781c+dmKd65rh/mutkuBGRhhYrAnXK6wlDWXiEZkaVW3fr//FjQQMQv1VqJMIxxZqa WfB5TEzB7VKjAkMPkv3rtoZfoRF4nc8EEoaFbun3jg0YpV/trzuA8Pz2o1ovwLxVXrxf n2Bg==
X-Received: by 10.180.223.68 with SMTP id qs4mr10023290wic.10.1411328858482; Sun, 21 Sep 2014 12:47:38 -0700 (PDT)
Received: from [10.0.0.4] (bzq-79-178-57-7.red.bezeqint.net. [79.178.57.7]) by mx.google.com with ESMTPSA id s1sm9687719wiw.6.2014.09.21.12.47.37 for <ipsec@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Sep 2014 12:47:38 -0700 (PDT)
Message-ID: <541F2B59.8070600@gmail.com>
Date: Sun, 21 Sep 2014 22:47:37 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: ipsec <ipsec@ietf.org>
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/OIWTs7rhhNGEAzhn1xradqkc3EU
Subject: [IPsec] Adoption: MOBIKEv2: MOBIKE extension for Transport mode
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Sep 2014 19:47:41 -0000

<html style="direction: ltr;">
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    <style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
  </head>
  <body style="direction: ltr;" bidimailui-charset-is-forced="true"
    text="#000000" bgcolor="#FFFFFF">
    Dear working group,<br>
    <br>
    Based on the feedback we received this week, we do not have enough
    support to adopt this document, in its current form, as a working
    group document. If the document's scope changes significantly in the
    future, we may want to reconsider this decision.<br>
    <br>
    Thanks,<br>
        Paul and Yaron<br>
  </body>
</html>


From nobody Sun Sep 21 12:52:41 2014
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446AD1A020A for <ipsec@ietfa.amsl.com>; Sun, 21 Sep 2014 12:52:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.276
X-Spam-Level: 
X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RH9kwMY1Lhqu for <ipsec@ietfa.amsl.com>; Sun, 21 Sep 2014 12:52:39 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 654771A01E5 for <ipsec@ietf.org>; Sun, 21 Sep 2014 12:52:39 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id em10so1839917wid.17 for <ipsec@ietf.org>; Sun, 21 Sep 2014 12:52:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=RXmhsAn1/zDQJZIrBQdyh57b091UiK9sucXHMW7rk3Q=; b=K2nT4VornDukLX1uvzftSD79aKA1WGuyk9XJ3Ww33gWCEJeVydHC/YOcucap9DYmeQ Enrfhpymc7U+MsUkc8UQ6VwhYpTCZDYypPDMShvHxCx4FSAoiIPa1A51zHy87H6awc07 95XIDAgx7rt/G44kyzM0KyG/7M4rNuJU1xMNsmtiEz+93jeQ7MU6vu/IcKTvrgbEMzYX U6d8FdhtQeIWl9XRDhAvubcNafoRuMUay1uf7Sf6yIQ3a3PBqALN4fDNwS07mxTR7Bbc evyqeoZFsv3dQS+AomNMTvCdcB5QgCOTPBd4PBZlLoDYv74JWhIMSY2vneniar7WDfEK Rk3A==
X-Received: by 10.180.14.101 with SMTP id o5mr11084871wic.25.1411329158045; Sun, 21 Sep 2014 12:52:38 -0700 (PDT)
Received: from [10.0.0.4] (bzq-79-178-57-7.red.bezeqint.net. [79.178.57.7]) by mx.google.com with ESMTPSA id a5sm9913862wjy.20.2014.09.21.12.52.37 for <ipsec@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Sep 2014 12:52:37 -0700 (PDT)
Message-ID: <541F2C84.7050805@gmail.com>
Date: Sun, 21 Sep 2014 22:52:36 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: ipsec <ipsec@ietf.org>
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/WgjqCNrELXPOSvj8VRg97q3BKzU
Subject: [IPsec] Call for adoption: Client Puzzles
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Sep 2014 19:52:40 -0000

<html style="direction: ltr;">
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    <style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
  </head>
  <body style="direction: ltr;" bidimailui-charset-is-forced="true"
    text="#000000" bgcolor="#FFFFFF">
    <font color="#000000">
      <pre style="margin: 0em;">Dear working group,

</pre>
      <tt>This is a call for adopting draft-nir-ipsecme-puzzles-00 as a
      </tt><tt>WG document. Please respond to this mail with a Yes or No
        and a short </tt><tt>rationale, at latest by Friday Sep. 26.<br>
        <br>
      </tt>
      <pre style="margin: 0em;">Thanks,
	Yaron

</pre>
    </font>
  </body>
</html>


From nobody Mon Sep 22 04:56:51 2014
Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950CB1A00A8 for <ipsec@ietfa.amsl.com>; Mon, 22 Sep 2014 04:56:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.793
X-Spam-Level: 
X-Spam-Status: No, score=0.793 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Er3SVWs_pyKh for <ipsec@ietfa.amsl.com>; Mon, 22 Sep 2014 04:56:47 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3383C1A00A7 for <ipsec@ietf.org>; Mon, 22 Sep 2014 04:56:47 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s8MBueDi026773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Sep 2014 14:56:40 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s8MBueqJ029010; Mon, 22 Sep 2014 14:56:40 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21536.3704.657354.303759@fireball.kivinen.iki.fi>
Date: Mon, 22 Sep 2014 14:56:40 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
In-Reply-To: <541F2C84.7050805@gmail.com>
References: <541F2C84.7050805@gmail.com>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 6 min
X-Total-Time: 5 min
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/qcxj_BO_qWrFoID-VrI_8hDZ8RY
Cc: ipsec <ipsec@ietf.org>
Subject: [IPsec]  Call for adoption: Client Puzzles
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Sep 2014 11:56:49 -0000

Yaron Sheffer writes:
> This is a call for adopting draft-nir-ipsecme-puzzles-00 as a WG
> document. Please respond to this mail with a Yes or No and a short
> rationale, at latest by Friday Sep. 26.

I think this problem is something we should consider, i.e start
working on the solution to it. I have not yet seen any attacks, but
if we get widespread IKEv2 uses in the future, I would expect all kind
of DoS attacks are going to spread, and it would be good idea if we
already have mechanism for protecting against them.

We had good discussion about this last time, and I think this item
requires bit more research to find out what would be the best way to
do this, especially if we think about those adaptive formats we
discussed in the meeting (i.e. where server can ask some work, and
client can do as much work as he can afford, and server then decides
whether that was enough or not).

For IPv6 we might need to think bit more, as there we cannot blacklist
known attackers that easily, so we might need to do something else
there.

So I think this is item we should work on, but I think there is quite
a lot of research and work in here to get something that would be good
way to solve this, and as we are not in hurry (meaning we are not
seeing such attacks now), we can use some time to get really good
solution out.
-- 
kivinen@iki.fi


From nobody Mon Sep 22 04:59:54 2014
Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600C21A1AAC for <ipsec@ietfa.amsl.com>; Mon, 22 Sep 2014 04:59:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level: 
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ElshonZ5n2v for <ipsec@ietfa.amsl.com>; Mon, 22 Sep 2014 04:59:51 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8B7A1A1AAA for <ipsec@ietf.org>; Mon, 22 Sep 2014 04:59:50 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s8MBxkuE008376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Sep 2014 14:59:46 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s8MBxk5s027723; Mon, 22 Sep 2014 14:59:46 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21536.3890.753309.212523@fireball.kivinen.iki.fi>
Date: Mon, 22 Sep 2014 14:59:46 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Yaron Sheffer <yaronf.ietf@gmail.com>, ipsec@ietf.org, Rahul Vaidya <rahul.stds@gmail.com>
In-Reply-To: <21521.33097.685133.508782@fireball.kivinen.iki.fi>
References: <CAEX11nYFEj-f8m-8fK-j7FH-EDavG0XgmJwonFMj_V_5eJHFzQ@mail.gmail.com> <54113486.9020601@gmail.com> <21521.33097.685133.508782@fireball.kivinen.iki.fi>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 1 min
X-Total-Time: 1 min
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/tzzSYfX3VzAd1D2R4orKblngRcc
Subject: Re: [IPsec] Mandatory Public Key based authentication with EAP
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Sep 2014 11:59:52 -0000

Tero Kivinen writes:
> Yaron Sheffer writes:
> > This is why RFC 5998 is listed as "updates 5996". So RFC 5998 does apply 
> > here. Note that it only applies in specific cases, and for specific EAP 
> > methods.
> > 
> > Yes, we should have updated the text in RFC 5996 to refer to 5998, but 
> > we forgot. Sigh.
> 
> Hmm.. I hope this does not mean we should update
> draft-kivinen-ikev2-rfc5996bis (now in AUTH48) to say something about
> this?

As there has not been any support in the list to add anything like
this to the draft-kivinen-ikev2-rfc5996bis, I assume we do not then
need to change it. 

> The RFC 5998 is standard track protocol that extends IKEv2 by
> including new notifications to negotiate the mutual EAP
> authentication, and also changes the payloads sent in the exchanges.
> 
> The current text in the draft is not incorrect, as if you follow the
> protocol described in this draft, then the in draft is correct:
> 
>    An implementation using EAP MUST also use a public-key-based
>    authentication of the server to the client before the EAP
>    authentication begins, even if the EAP method offers mutual
>    authentication.  This avoids having additional IKEv2 protocol
>    variations and protects the EAP data from active attackers.
> 
> What we could do, is to add reference to the RFC5998 there, but I
> think it might not be needed, as RFC5998 is clearly an extension to
> the IKEv2, and we do not need to list all extensions to IKEv2 in the
> specification.
> 
> What do others think? If we would earlier in the publication process,
> I would say go for it, but adding this kind of text in AUTH48 is not
> something I would like to be doing... 
-- 
kivinen@iki.fi


From nobody Mon Sep 22 07:30:26 2014
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F6E1A1AEB for <ipsec@ietfa.amsl.com>; Mon, 22 Sep 2014 07:30:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yS9MvI-4FAqo for <ipsec@ietfa.amsl.com>; Mon, 22 Sep 2014 07:30:22 -0700 (PDT)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E3A1A1AD4 for <ipsec@ietf.org>; Mon, 22 Sep 2014 07:30:21 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id n12so1078519wgh.23 for <ipsec@ietf.org>; Mon, 22 Sep 2014 07:30:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=fkGJuJoSYVEK15r4TD7TEtb/eWbDBTMEWCHI39dLFH4=; b=jMGHh/HFZRrK7p8vq+afvnx7Too81uOrEULAd9tOQNrHhHun+BtK4yOq/BCTN7RvnZ WlsFZRCdYMyDATm0ygsbjZksi2GSqfixhPLyxplRtLoiJ6jDi+8xSMXkCfLYK+LNBImt 3nHbQXKuxxy6zxnmQjloBdqlLzNnSufLOVeslSOoQQGSh3sRIhqGOLJC9pIvvNZBGoKD htjsM9IM9kXbQgFSR+T1F8uZFuSq3S/diVSKf/pQSZ91BO/qGUXPA4dpMF14NgrMeCEA hnIR5nOX2VAvh6LKmE4CckcVBUqT37zM3O/iALGpDngnr5vJlgaXrqOwee1BJakwBihC WcJQ==
X-Received: by 10.194.119.67 with SMTP id ks3mr3557652wjb.96.1411396220122; Mon, 22 Sep 2014 07:30:20 -0700 (PDT)
Received: from [10.2.0.78] (85-250-123-108.bb.netvision.net.il. [85.250.123.108]) by mx.google.com with ESMTPSA id om1sm12482772wjc.42.2014.09.22.07.30.18 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Sep 2014 07:30:19 -0700 (PDT)
Message-ID: <54203279.6050208@gmail.com>
Date: Mon, 22 Sep 2014 17:30:17 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: Tero Kivinen <kivinen@iki.fi>, ipsec@ietf.org,  Rahul Vaidya <rahul.stds@gmail.com>
References: <CAEX11nYFEj-f8m-8fK-j7FH-EDavG0XgmJwonFMj_V_5eJHFzQ@mail.gmail.com>	<54113486.9020601@gmail.com>	<21521.33097.685133.508782@fireball.kivinen.iki.fi> <21536.3890.753309.212523@fireball.kivinen.iki.fi>
In-Reply-To: <21536.3890.753309.212523@fireball.kivinen.iki.fi>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/JcGYpnxNFK1zVW59tFSZ3Sm_fEI
Subject: Re: [IPsec] Mandatory Public Key based authentication with EAP
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Sep 2014 14:30:25 -0000

So for the record, I do think we should add to RFC 5996, at the end of 
the paragraph that starts with "An implementation using EAP MUST also 
use a public-key-based" something like:

As an exception to this rule, public key authentication of the server is 
not required when using the extension defined in [RFC5998].

Thanks,
	Yaron


On 09/22/2014 02:59 PM, Tero Kivinen wrote:
>
> As there has not been any support in the list to add anything like
> this to the draft-kivinen-ikev2-rfc5996bis, I assume we do not then
> need to change it.
>


From nobody Mon Sep 22 09:38:22 2014
Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D304C1A1B1E for <ipsec@ietfa.amsl.com>; Mon, 22 Sep 2014 09:38:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.887
X-Spam-Level: 
X-Spam-Status: No, score=-0.887 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iH9UQvhjyZ25 for <ipsec@ietfa.amsl.com>; Mon, 22 Sep 2014 09:38:05 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 301D71A1B25 for <ipsec@ietf.org>; Mon, 22 Sep 2014 09:38:05 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B87E580416; Mon, 22 Sep 2014 12:38:03 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1411403883; bh=wJFSdYenY492Vrfy0jJErYeMOS7+EMhvzGdk0kSLLTY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=lZbGmNWE6juA6xG38g4aCu5wiB+qJWDeOYmy2TlouBU7e4IUbyYETMWm+LOzVRNF9 WfqhbVSxBCLnKinSy2vGzB3qzJM3KEmor17el4c7rAFtUMUlSFnBUrO2uQ537s9zzt 4+SyV3NfOWB0rmDnr1WpPk+g3WhRiSDj/v0eyVU4=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s8MGc2uD024979; Mon, 22 Sep 2014 12:38:03 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Mon, 22 Sep 2014 12:38:02 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Tero Kivinen <kivinen@iki.fi>
In-Reply-To: <21536.3704.657354.303759@fireball.kivinen.iki.fi>
Message-ID: <alpine.LFD.2.10.1409221232470.8544@bofh.nohats.ca>
References: <541F2C84.7050805@gmail.com> <21536.3704.657354.303759@fireball.kivinen.iki.fi>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/ixJD8ByCcx1_6RMESqdmafuiQoc
Cc: ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] Call for adoption: Client Puzzles
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Sep 2014 16:38:12 -0000

On Mon, 22 Sep 2014, Tero Kivinen wrote:

> Yaron Sheffer writes:
>> This is a call for adopting draft-nir-ipsecme-puzzles-00 as a WG
>> document. Please respond to this mail with a Yes or No and a short
>> rationale, at latest by Friday Sep. 26.

> So I think this is item we should work on, but I think there is quite
> a lot of research and work in here to get something that would be good
> way to solve this, and as we are not in hurry (meaning we are not
> seeing such attacks now), we can use some time to get really good
> solution out.

I agree with Tero. It's worth thinking about, but the current solution
based on CPU power seems to be in favour of the attacker, not the
legitimate client. It would be nice if we can come up with a better
solution that gives clients a better advantage.

For example, I think currently, you are better of checking for the the
CERTREQ SHA1 payload to determine which is a legitimate client, although
it does take more processing of the payloads. And of course the SHA1 is
not a very well kept secret....

So, I'm in favour of adoption of the document, but not in favour of the
currently proposed CPU-bound puzzle solution.

Paul


From nobody Mon Sep 22 10:05:37 2014
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A3A1A1B9D for <ipsec@ietfa.amsl.com>; Mon, 22 Sep 2014 10:05:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyq76D5WMy9o for <ipsec@ietfa.amsl.com>; Mon, 22 Sep 2014 10:05:22 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72111A1B93 for <ipsec@ietf.org>; Mon, 22 Sep 2014 10:05:21 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id k14so3031212wgh.24 for <ipsec@ietf.org>; Mon, 22 Sep 2014 10:05:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hkeRJbCEk66epxHhhQrRBfqKP4OqgyXCMXe3RT4IURE=; b=dVXz6Iwrm4CTTU2MLSU77yShWb25dvkuCMFL6mlO1AwwiPVwnPVnczn7FxDHWwDydm pFGGsZLzVRvgSf4a2VEq9jPN5hpQxjHqA8opayZ0xAUv240oCOqvxAPKmDcmbI02hU6/ u/Qvoma+FEBJD0NTOiVGxiqodCUt3KO608xM4/teuKACtJkY9DvBQdWiyW0+RIjBDT3s OtnpdaMIcCVIDkYH8r/EVtE5cA2N2KoWMZF5LFpr2TjL7ixpi83977PrZKWHJUHHB7xs 2XVzN35CfqDXg6S3UYDyKXkZurTBLYE7X9FlNd1dAGh0SvH8+C1KSZN7nwOOSJD749Dl oyuA==
X-Received: by 10.180.97.101 with SMTP id dz5mr16417887wib.52.1411405520370; Mon, 22 Sep 2014 10:05:20 -0700 (PDT)
Received: from [10.0.0.4] ([109.66.16.60]) by mx.google.com with ESMTPSA id ew1sm12940463wjb.31.2014.09.22.10.05.19 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Sep 2014 10:05:19 -0700 (PDT)
Message-ID: <542056CE.2060700@gmail.com>
Date: Mon, 22 Sep 2014 20:05:18 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: Paul Wouters <paul@nohats.ca>, Tero Kivinen <kivinen@iki.fi>
References: <541F2C84.7050805@gmail.com> <21536.3704.657354.303759@fireball.kivinen.iki.fi> <alpine.LFD.2.10.1409221232470.8544@bofh.nohats.ca>
In-Reply-To: <alpine.LFD.2.10.1409221232470.8544@bofh.nohats.ca>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/b3voEGgl26szBebXmaI1rt2h4wg
Cc: ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] Call for adoption: Client Puzzles
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Sep 2014 17:05:35 -0000

>
> So, I'm in favour of adoption of the document, but not in favour of the
> currently proposed CPU-bound puzzle solution.
>
> Paul

With WG chair hat on: We should adopt this document if the problem it 
raises needs to be solved (I would say the problem is, DDoS protection 
in the presence of botnets) AND if the document actually solves the 
problem or can be modified without radical changes to do so.

If radical changes are needed, let's by all means discuss them first on 
the list, and then adopt the document.

Thanks,
	Yaron


From nobody Mon Sep 22 12:56:56 2014
Return-Path: <ynir.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A731A1B35 for <ipsec@ietfa.amsl.com>; Mon, 22 Sep 2014 12:56:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.599
X-Spam-Level: 
X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52ip5jjdrIGw for <ipsec@ietfa.amsl.com>; Mon, 22 Sep 2014 12:56:52 -0700 (PDT)
Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87CCA1A1B2B for <ipsec@ietf.org>; Mon, 22 Sep 2014 12:56:52 -0700 (PDT)
Received: by mail-we0-f169.google.com with SMTP id k48so3502921wev.14 for <ipsec@ietf.org>; Mon, 22 Sep 2014 12:56:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=wNSHYDyg7uIr9MlMdYNC4e0JFAUL894Rw9/9mFoF+54=; b=e/6ucA3t7a07Zf+W3dShjzZKooiJhkU2OvmPI1XfE0vl/CBmv2/4tvBaPcdt/elSv4 R3m1wYSyZD802V86F4APLybeHZCa2PX8k0yJTq4FwWaXj1VwTXYwCSaEKtTTiPS1bnH4 hhDkA8TVYpIBt1I5DnhtcSqWaNasHkSIj5c9BFS6IVg6O3HOPi63Q2rwwuWhrmpMR2eN AOO59TzOOAxwzgTfg63T9bOmfFiHVFqrtcQyaTJebJboj5qxTPJVPbL0sq6KWfZa8QJF TEK6ASozV9nouibV1Iwi1RnLfbmnuk/BPh0H48u7sRYaIxfYXcDeaIL28KZ2sFl1oi7D 5YgQ==
X-Received: by 10.180.86.33 with SMTP id m1mr17131759wiz.11.1411415811149; Mon, 22 Sep 2014 12:56:51 -0700 (PDT)
Received: from [192.168.1.103] (IGLD-84-228-192-250.inter.net.il. [84.228.192.250]) by mx.google.com with ESMTPSA id q2sm13160323wiy.23.2014.09.22.12.56.50 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Sep 2014 12:56:50 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_FC2AF3E2-96BD-441E-BF2C-1D544FAA87B8"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <541F2C84.7050805@gmail.com>
Date: Mon, 22 Sep 2014 22:56:47 +0300
Message-Id: <9A31C308-7D58-46EA-9CB5-47692A32E423@gmail.com>
References: <541F2C84.7050805@gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Ihk7Y6M8B4YhyIRZ5isWYoGU0nA
Cc: ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] Call for adoption: Client Puzzles
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Sep 2014 19:56:54 -0000

--Apple-Mail=_FC2AF3E2-96BD-441E-BF2C-1D544FAA87B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hi.

As I=92m the document author, it=92s no surprise that my vote is Yes.

Much like Paul Wouters, I would have liked to have a kind of puzzle that =
did not give an advantage to attacking desktops over legitimate =
smartphones. But all proposals for puzzles have been just as CPU-bound =
as the partial hash break in the current draft, or the bitcoin-style =
puzzle that I like better now.

One proposal that I kind of liked (and I=92m sorry I=92ve forgotten who =
suggested it) was to relegate the puzzle to a second line of defense, =
through the use of some kind of anti-dos ticket. The ticket would be a =
bearer token (perhaps an encrypted timestamp) that would allow the =
bearer to get by with a much easier version of the puzzle. The responder =
would make an effort to prevent replay of tickets (as in remembering the =
last 1000 valid tickets), which would mean that to consistently get the =
easy version of the puzzle, the attackers would need to collect a =
greater amount of tickets than the responder stores.

In any case, I think the document should be adopted, and then we can =
change the puzzle algorithm according to the group=92s preference and =
add a fast path for repeat visitors if we think that=92s a good idea.

Yoav


On Sep 21, 2014, at 10:52 PM, Yaron Sheffer <yaronf.ietf@gmail.com> =
wrote:

> Dear working group,
>=20
> This is a call for adopting draft-nir-ipsecme-puzzles-00 as a WG =
document. Please respond to this mail with a Yes or No and a short =
rationale, at latest by Friday Sep. 26.
>=20
> Thanks,
> 	Yaron


--Apple-Mail=_FC2AF3E2-96BD-441E-BF2C-1D544FAA87B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;">Hi.<div><br></div><div>As I=92m the document author, =
it=92s no surprise that my vote is Yes.</div><div><br></div><div>Much =
like Paul Wouters, I would have liked to have a kind of puzzle that did =
not give an advantage to attacking desktops over legitimate smartphones. =
But all proposals for puzzles have been just as CPU-bound as the partial =
hash break in the current draft, or the bitcoin-style puzzle that I like =
better now.</div><div><br></div><div>One proposal that I kind of liked =
(and I=92m sorry I=92ve forgotten who suggested it) was to relegate the =
puzzle to a second line of defense, through the use of some kind of =
anti-dos ticket. The ticket would be a bearer token (perhaps an =
encrypted timestamp) that would allow the bearer to get by with a much =
easier version of the puzzle. The responder would make an effort to =
prevent replay of tickets (as in remembering the last 1000 valid =
tickets), which would mean that to consistently get the easy version of =
the puzzle, the attackers would need to collect a greater amount of =
tickets than the responder stores.</div><div><br></div><div>In any case, =
I think the document should be adopted, and then we can change the =
puzzle algorithm according to the group=92s preference and add a fast =
path for repeat visitors if we think that=92s a good =
idea.</div><div><br></div><div>Yoav</div><div><br></div><div><br><div><div=
>On Sep 21, 2014, at 10:52 PM, Yaron Sheffer &lt;<a =
href=3D"mailto:yaronf.ietf@gmail.com">yaronf.ietf@gmail.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div bidimailui-charset-is-forced=3D"true" text=3D"#000000" =
bgcolor=3D"#FFFFFF" style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
direction: ltr;"><font><pre style=3D"margin: 0em;">Dear working group,

</pre><tt>This is a call for adopting draft-nir-ipsecme-puzzles-00 as =
a<span class=3D"Apple-converted-space">&nbsp;</span></tt><tt>WG =
document. Please respond to this mail with a Yes or No and a short<span =
class=3D"Apple-converted-space">&nbsp;</span></tt><tt>rationale, at =
latest by Friday Sep. 26.<br><br></tt><pre style=3D"margin: =
0em;">Thanks,
	Yaron
</pre></font></div></blockquote></div><br></div></body></html>=

--Apple-Mail=_FC2AF3E2-96BD-441E-BF2C-1D544FAA87B8--


From nobody Tue Sep 23 06:14:49 2014
Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1181A1AA7 for <ipsec@ietfa.amsl.com>; Tue, 23 Sep 2014 06:14:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeyCRcYAb7zS for <ipsec@ietfa.amsl.com>; Tue, 23 Sep 2014 06:14:45 -0700 (PDT)
Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF6961A00A8 for <ipsec@ietf.org>; Tue, 23 Sep 2014 06:14:44 -0700 (PDT)
Received: by mail-lb0-f173.google.com with SMTP id 10so6897809lbg.18 for <ipsec@ietf.org>; Tue, 23 Sep 2014 06:14:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=eVOUSeqETrpxLiFCthV2zvvDwlU5P3Hx5evTa2w+6Yw=; b=yDijvQQ0TjEayvKyvvi8qA0ETWl3OF2rF97zfvPgacDTCzqhuio7MVafo66Nja/e7J 7ZxaMXyAWQSERINUkx1g5WNSWPK676hZPxW3R27zNODkP9IcDBcCIVOcx11Xp0JT1/3T FdoNUS++Sk8FLxWPvvyCfv8wXhsJ7+7FGobLZLDMWcT/hdLiciLmwcLCnrC0S/9VrYPZ g0sbrREggubz/4iYA9T6/d+/e/wKYd0ue1KIoem1GZReeu8Z5CNqReqOBerPO910KeE8 +t4MkEL34bOSCZxyMOUdNSw8uxbt3ioeY/Pa6TeAcqfZo5EaHHyPvV4BCji50xmqyQRw lZ3A==
X-Received: by 10.152.37.169 with SMTP id z9mr10254077laj.66.1411478083016; Tue, 23 Sep 2014 06:14:43 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id jv4sm1687536lbc.35.2014.09.23.06.14.41 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 23 Sep 2014 06:14:42 -0700 (PDT)
Message-ID: <8139F5C1D4ED4E2181D40A58434ACE3A@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Tero Kivinen" <kivinen@iki.fi>
References: <F68C660364DABE41AF4617F517EF548411707BE2@ESESSMB309.ericsson.se><21493.55390.157248.181030@fireball.kivinen.iki.fi><C949D5C9077942ACA31105FE4156154E@buildpc> <21504.31762.454252.961126@fireball.kivinen.iki.fi> <DC2FED9C253548E5875C4E5CCCFD40D0@buildpc> <4A81BADF09C04D50BFA83D59711A0EF7@buildpc>
Date: Tue, 23 Sep 2014 17:14:50 +0400
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/i7k56zz0kbIbEFds4h_5a-swG6g
Cc: ipsec@ietf.org
Subject: [IPsec]  More nits in draft-kivinen-ipsecme-ikev2-rfc5996bis-04
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Sep 2014 13:14:46 -0000

1. Section 3.15.1:

   o  APPLICATION_VERSION - The version or application information of
      the IPsec host.  This is a string of printable ASCII characters
      that is NOT null terminated.

"NOT" is uppercase. Although it might be an intention to ephasise
the fact, that it is not null terminated, but it looks like RFC2119 word,
that is not the case.


2. Section 3.16:

   o  Type (1 octet) is present only if the Code field is Request (1) or
      Response (2).  For other codes, the EAP message length MUST be
      four octets and the Type and Type_Data fields MUST NOT be present.
      In a Request (1) message, Type indicates the data being requested.
      In a Response (2) message, Type MUST either be Nak or match the
      type of the data requested.  Note that since IKE passes an
      indication of initiator identity in the first message in the
      IKE_AUTH exchange, the responder SHOULD NOT send EAP Identity
      requests (type 1).  The initiator MAY, however, respond to such
      requests if it receives them.
...

   Note that since IKE passes an indication of initiator identity in the
   first message in the IKE_AUTH exchange, the responder should not send
   EAP Identity requests.  The initiator may, however, respond to such
   requests if it receives them.

The last para in the section is absolutely equal to the last two sentences
in the cited bullet, except that it doesn't use RFC2119 wording. 
I failed to see that it adds any value here.


From nobody Tue Sep 23 06:47:57 2014
Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A7D1A1ADC for <ipsec@ietfa.amsl.com>; Tue, 23 Sep 2014 06:47:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level: 
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eP6PI7U-73FQ for <ipsec@ietfa.amsl.com>; Tue, 23 Sep 2014 06:47:55 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0FEB1A802F for <ipsec@ietf.org>; Tue, 23 Sep 2014 06:47:54 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s8NDln3q010377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 Sep 2014 16:47:49 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s8NDlnuK026230; Tue, 23 Sep 2014 16:47:49 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21537.31237.807412.599380@fireball.kivinen.iki.fi>
Date: Tue, 23 Sep 2014 16:47:49 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: "Valery Smyslov" <svanru@gmail.com>
In-Reply-To: <4A81BADF09C04D50BFA83D59711A0EF7@buildpc>
References: <F68C660364DABE41AF4617F517EF548411707BE2@ESESSMB309.ericsson.se> <21493.55390.157248.181030@fireball.kivinen.iki.fi> <C949D5C9077942ACA31105FE4156154E@buildpc> <21504.31762.454252.961126@fireball.kivinen.iki.fi> <DC2FED9C253548E5875C4E5CCCFD40D0@buildpc> <4A81BADF09C04D50BFA83D59711A0EF7@buildpc>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 0 min
X-Total-Time: 0 min
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/_6FPfLn0HQNgYXidZnNoCjrElhs
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Typos in draft-kivinen-ipsecme-ikev2-rfc5996bis-04
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Sep 2014 13:47:57 -0000

Valery Smyslov writes:
> In Section 3.8 (Authentication Payload) the description
> of the 3-octet RESERVED field is absent. I think it is a typo,
> as in all other cases, when reserved field is present
> in payload (KE, ID, TS, CP), its description is given.

Fix sent to the RFC editor during the AUTH48d... 
-- 
kivinen@iki.fi


From nobody Tue Sep 23 06:48:38 2014
Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272E81A86E3 for <ipsec@ietfa.amsl.com>; Tue, 23 Sep 2014 06:48:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level: 
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFDcuH7CE64H for <ipsec@ietfa.amsl.com>; Tue, 23 Sep 2014 06:48:36 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFD571A86E1 for <ipsec@ietf.org>; Tue, 23 Sep 2014 06:48:35 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s8NDmXTQ000750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 Sep 2014 16:48:33 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s8NDmXXu004377; Tue, 23 Sep 2014 16:48:33 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21537.31281.324541.343516@fireball.kivinen.iki.fi>
Date: Tue, 23 Sep 2014 16:48:33 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: "Valery Smyslov" <svanru@gmail.com>
In-Reply-To: <EE25ACA922BC4A70852C7BD495162228@buildpc>
References: <F68C660364DABE41AF4617F517EF548411707BE2@ESESSMB309.ericsson.se> <21493.55390.157248.181030@fireball.kivinen.iki.fi> <C949D5C9077942ACA31105FE4156154E@buildpc> <21504.31762.454252.961126@fireball.kivinen.iki.fi> <DC2FED9C253548E5875C4E5CCCFD40D0@buildpc> <4A81BADF09C04D50BFA83D59711A0EF7@buildpc> <EAFA100B50B24E0D81E9BCA44CAE9D94@buildpc> <alpine.LFD.2.10.1409180926200.1198@bofh.nohats.ca> <EE25ACA922BC4A70852C7BD495162228@buildpc>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 1 min
X-Total-Time: 0 min
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/iX4oAla004YYmgeyW0tm8poeIQo
Cc: ipsec@ietf.org, Paul Wouters <paul@nohats.ca>
Subject: Re: [IPsec] Typos in draft-kivinen-ipsecme-ikev2-rfc5996bis-04
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Sep 2014 13:48:37 -0000

Valery Smyslov writes:
>    o  Selector Length - Specifies the length of this Traffic Selector
>       substructure including the header.
> 
> No indication of how "Selector Length" (it is 2 octets) should be
> treated. 

Fix sent in for the rfc-editor...
-- 
kivinen@iki.fi


From nobody Tue Sep 23 06:53:53 2014
Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDBD1A1AC8 for <ipsec@ietfa.amsl.com>; Tue, 23 Sep 2014 06:53:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level: 
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vVPFYkGD8a6 for <ipsec@ietfa.amsl.com>; Tue, 23 Sep 2014 06:53:47 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7E1D1A797C for <ipsec@ietf.org>; Tue, 23 Sep 2014 06:53:46 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s8NDrhm7015173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 Sep 2014 16:53:43 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s8NDrhid005497; Tue, 23 Sep 2014 16:53:43 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21537.31591.465157.509866@fireball.kivinen.iki.fi>
Date: Tue, 23 Sep 2014 16:53:43 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: "Valery Smyslov" <svanru@gmail.com>
In-Reply-To: <8139F5C1D4ED4E2181D40A58434ACE3A@buildpc>
References: <F68C660364DABE41AF4617F517EF548411707BE2@ESESSMB309.ericsson.se> <21493.55390.157248.181030@fireball.kivinen.iki.fi> <C949D5C9077942ACA31105FE4156154E@buildpc> <21504.31762.454252.961126@fireball.kivinen.iki.fi> <DC2FED9C253548E5875C4E5CCCFD40D0@buildpc> <4A81BADF09C04D50BFA83D59711A0EF7@buildpc> <8139F5C1D4ED4E2181D40A58434ACE3A@buildpc>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 4 min
X-Total-Time: 4 min
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/nPCrVSVVa82MAEPhl6hHT-lDUK0
Cc: ipsec@ietf.org
Subject: [IPsec]   More nits in draft-kivinen-ipsecme-ikev2-rfc5996bis-04
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Sep 2014 13:53:49 -0000

Valery Smyslov writes:
> 1. Section 3.15.1:
> 
>    o  APPLICATION_VERSION - The version or application information of
>       the IPsec host.  This is a string of printable ASCII characters
>       that is NOT null terminated.
> 
> "NOT" is uppercase. Although it might be an intention to ephasise
> the fact, that it is not null terminated, but it looks like RFC2119 word,
> that is not the case.

That "NOT" is intentional and it is used to emphasize the fact there
is no terminator. 

> 2. Section 3.16:
> 
>    o  Type (1 octet) is present only if the Code field is Request (1) or
>       Response (2).  For other codes, the EAP message length MUST be
>       four octets and the Type and Type_Data fields MUST NOT be present.
>       In a Request (1) message, Type indicates the data being requested.
>       In a Response (2) message, Type MUST either be Nak or match the
>       type of the data requested.  Note that since IKE passes an
>       indication of initiator identity in the first message in the
>       IKE_AUTH exchange, the responder SHOULD NOT send EAP Identity
>       requests (type 1).  The initiator MAY, however, respond to such
>       requests if it receives them.
> ...
> 
>    Note that since IKE passes an indication of initiator identity in the
>    first message in the IKE_AUTH exchange, the responder should not send
>    EAP Identity requests.  The initiator may, however, respond to such
>    requests if it receives them.
> 
> The last para in the section is absolutely equal to the last two sentences
> in the cited bullet, except that it doesn't use RFC2119 wording. 
> I failed to see that it adds any value here.

It is to emphasize that you really, really need to leave out those
identity requests. We didn't want to such important thing stay hidden
under the bulleted list describing the fields in payload...

And it has already been fixed during the rfc editor process to have
exactly same RFC2119 wording that the text above has. Current text
says:

----------------------------------------------------------------------
   o  Type (1 octet) - Present only if the Code field is Request (1) or
      Response (2).  For other codes, the EAP message length MUST be
      four octets and the Type and Type_Data fields MUST NOT be present.
      In a Request (1) message, Type indicates the data being requested.
      In a Response (2) message, Type MUST either be Nak or match the
      type of the data requested.  Note that since IKE passes an
      indication of initiator identity in the first message in the
      IKE_AUTH exchange, the responder SHOULD NOT send EAP Identity
      requests (type 1).  The initiator MAY, however, respond to such
      requests if it receives them.

   o  Type_Data (variable length) - Varies with the Type of Request and
      the associated Response.  For the documentation of the EAP
      methods, see [EAP].

   Note that since IKE passes an indication of initiator identity in the
   first message in the IKE_AUTH exchange, the responder SHOULD NOT send
   EAP Identity requests.  The initiator MAY, however, respond to such
   requests if it receives them.
-- 
kivinen@iki.fi


From nobody Tue Sep 23 11:24:37 2014
Return-Path: <mcr@sandelman.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7717A1A884A for <ipsec@ietfa.amsl.com>; Tue, 23 Sep 2014 11:24:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.687
X-Spam-Level: 
X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5g2SHcL1VSbh for <ipsec@ietfa.amsl.com>; Tue, 23 Sep 2014 11:24:32 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB8A1A8847 for <ipsec@ietf.org>; Tue, 23 Sep 2014 11:24:32 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5998020012; Tue, 23 Sep 2014 14:29:45 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 561CF63AE9; Tue, 23 Sep 2014 14:24:31 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3F01C63AD5; Tue, 23 Sep 2014 14:24:31 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <9A31C308-7D58-46EA-9CB5-47692A32E423@gmail.com>
References: <541F2C84.7050805@gmail.com> <9A31C308-7D58-46EA-9CB5-47692A32E423@gmail.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Tue, 23 Sep 2014 14:24:31 -0400
Message-ID: <31304.1411496671@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/MhqpOGNT1fWtbNVa-gzRJWSd2QE
Cc: ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] Call for adoption: Client Puzzles
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Sep 2014 18:24:33 -0000

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Yoav Nir <ynir.ietf@gmail.com> wrote:
    > One proposal that I kind of liked (and I=E2=80=99m sorry I=E2=80=99ve=
 forgotten who
    > suggested it) was to relegate the puzzle to a second line of defense,
    > through the use of some kind of anti-dos ticket. The ticket would be a
    > bearer token (perhaps an encrypted timestamp) that would allow the
    > bearer to get by with a much easier version of the puzzle. The

Would this ticket be provided in a Notify, after AUTHentication, in a
previous PARENT-SA?

    > In any case, I think the document should be adopted, and then we can
    > change the puzzle algorithm according to the group=E2=80=99s preferen=
ce and add
    > a fast path for repeat visitors if we think that=E2=80=99s a good ide=
a.

+1

=2D-
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-




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

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

iQEVAwUBVCG63oCLcPvd0N1lAQLeSAf/VpH+HxO+ALEi5FHk/igsFLgtpOfmBnjY
gI/6ntq93k+T2GhE27Syh7b7EoGEpzxiaMMI5VTq66kHMXwDh+hqHn4gZcLDpVXW
9gwe0xP7rDa2lk28ODXci6MHmZomipiR83MMo8WmUNzaLHm2NVSJMEW0R8o+ajbR
hjmUHz4xDAGAH+H9UpEVWJ5Q2ArePgWQ110ljAvLU6xEsAAo+iMaIoS87Dk0/yQ1
MVnMZW7KctYQcHPjx6tn9Ebc1kCxIyhfh81PG/cqLCZAoFHtTELuFDYxHbvidFtj
p9rVC7x4iC5OqOEey1efji+Dn1BV/EMPyvIVCrwBvmu5FPta/ep6bw==
=Hc8l
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Tue Sep 23 11:35:11 2014
Return-Path: <ynir.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB941A8876 for <ipsec@ietfa.amsl.com>; Tue, 23 Sep 2014 11:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.23
X-Spam-Level: 
X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0cGD5s1hAOB for <ipsec@ietfa.amsl.com>; Tue, 23 Sep 2014 11:35:03 -0700 (PDT)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6002D1A88C6 for <ipsec@ietf.org>; Tue, 23 Sep 2014 11:33:23 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id z12so1125864wgg.3 for <ipsec@ietf.org>; Tue, 23 Sep 2014 11:33:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uyfhq6BIDvoFPd8uqhf741ZO0vZlDeessjO1d9UCabw=; b=VrG/7rKGiOSBMzGzrVvLrMAQ/v/tb6IxAL7gEhpMJP3sKzmE9WdY/j0JD6Gez9Jkr5 4u0Kp+WBxf2tV7tlzDqZoeHI2wSjdVWF0xeSkgMNjcA09LohCff+GpdIZ7sP0iPXRtVO qhbpzndkdoN5kglAs3fVE3B58iCzcJnpCkQ8ot0TM5+KDeQKli9BAppq9LrhF8H3vqH/ HuuufEO+koJXDDu8Ea+eN6rJfatxFXRCA9hleloIf+IWuUh5XN6tiilQACrTqkJpYIuY KTaAQ6m8zzDylBGNi8VtNcnVBBIK7dnBSnn8BtH+RNs83dXKkHvkVq4VZB89DMden8mD aXjg==
X-Received: by 10.180.211.36 with SMTP id mz4mr25473113wic.39.1411497201963; Tue, 23 Sep 2014 11:33:21 -0700 (PDT)
Received: from [192.168.1.100] (IGLD-84-228-231-213.inter.net.il. [84.228.231.213]) by mx.google.com with ESMTPSA id pm6sm16798667wjb.36.2014.09.23.11.33.20 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Sep 2014 11:33:21 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <31304.1411496671@sandelman.ca>
Date: Tue, 23 Sep 2014 21:33:13 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <E2E040B4-06D9-4EE1-A606-9D60AC0D0663@gmail.com>
References: <541F2C84.7050805@gmail.com> <9A31C308-7D58-46EA-9CB5-47692A32E423@gmail.com> <31304.1411496671@sandelman.ca>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/tuVHdHXnm6g3YWDfaPaLnS4IHU4
Cc: ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] Call for adoption: Client Puzzles
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Sep 2014 18:35:04 -0000

On Sep 23, 2014, at 9:24 PM, Michael Richardson <mcr+ietf@sandelman.ca> =
wrote:

>=20
> Yoav Nir <ynir.ietf@gmail.com> wrote:
>> One proposal that I kind of liked (and I=92m sorry I=92ve forgotten =
who
>> suggested it) was to relegate the puzzle to a second line of defense,
>> through the use of some kind of anti-dos ticket. The ticket would be =
a
>> bearer token (perhaps an encrypted timestamp) that would allow the
>> bearer to get by with a much easier version of the puzzle. The
>=20
> Would this ticket be provided in a Notify, after AUTHentication, in a
> previous PARENT-SA?

Since it=92s provided by the responder, it can go in the AUTH response. =
And yes, it=92s a =93have an easier time getting in next time=94 kind of =
ticket, so we don=92t need solid replay protection, just best effort =
replay protection.

Come to think of it, the mechanisms should only be part of the draft. =
The purpose of the draft is DDOS protection. So it should cover all =
aspects: aging policy for the half-open SA database, limiting half-open =
SAs from single IPv4 addresses or IPv6 prefixes, probably some other =
things. There=92s more to protecting a server on the internet than just =
implementing a protocol extension.

Yoav=


From nobody Thu Sep 25 04:27:17 2014
Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497B61A6F61 for <ipsec@ietfa.amsl.com>; Thu, 25 Sep 2014 04:27:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level: 
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDb408XYgvrD for <ipsec@ietfa.amsl.com>; Thu, 25 Sep 2014 04:27:15 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC111A1A73 for <ipsec@ietf.org>; Thu, 25 Sep 2014 04:27:14 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s8PBRCC9029211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Sep 2014 14:27:12 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s8PBRCEH026414; Thu, 25 Sep 2014 14:27:12 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-ID: <21539.64527.894355.115813@fireball.kivinen.iki.fi>
Date: Thu, 25 Sep 2014 14:27:11 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Michael Richardson <mcr+ietf@sandelman.ca>
In-Reply-To: <31304.1411496671@sandelman.ca>
References: <541F2C84.7050805@gmail.com> <9A31C308-7D58-46EA-9CB5-47692A32E423@gmail.com> <31304.1411496671@sandelman.ca>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 5 min
X-Total-Time: 4 min
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/66mUrCL2tx7jNGmLJy_hEcb24XE
Cc: ipsec <ipsec@ietf.org>, Yoav Nir <ynir.ietf@gmail.com>
Subject: Re: [IPsec] Call for adoption: Client Puzzles
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Sep 2014 11:27:16 -0000

Michael Richardson writes:
> Yoav Nir <ynir.ietf@gmail.com> wrote:
>     > One proposal that I kind of liked (and I=E2=80=99m sorry I=E2=80=
=99ve forgotten who
>     > suggested it) was to relegate the puzzle to a second line of de=
fense,
>     > through the use of some kind of anti-dos ticket. The ticket wou=
ld be a
>     > bearer token (perhaps an encrypted timestamp) that would allow =
the
>     > bearer to get by with a much easier version of the puzzle. The
>=20
> Would this ticket be provided in a Notify, after AUTHentication, in a=

> previous PARENT-SA=3F

Wouldn't it be better to use IKEv2 session resumption (RFC 5723) for
those clients coming back.

I.e if you resume old existing session then you do not need to do
puzzle... And after the resume, the ticket is usually changed again,
so the ticket would always be fresh.
--=20
kivinen@iki.fi


From nobody Thu Sep 25 10:02:48 2014
Return-Path: <ynir.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522061A871C for <ipsec@ietfa.amsl.com>; Thu, 25 Sep 2014 10:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-P087zTy26O for <ipsec@ietfa.amsl.com>; Thu, 25 Sep 2014 10:02:44 -0700 (PDT)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE6E11A86F2 for <ipsec@ietf.org>; Thu, 25 Sep 2014 10:02:43 -0700 (PDT)
Received: by mail-wi0-f179.google.com with SMTP id d1so9925597wiv.12 for <ipsec@ietf.org>; Thu, 25 Sep 2014 10:02:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6kEtONFIojapPBhZ8dTisjZASnk5qabssaIOjY3D9qs=; b=mclsY2g2MwfTfJNTO8yEjjMuco3Q3ZUQNA43DWF6HRLjOlXRvAYic9doYLzjvUgRQf v4DynzyktTxd1yVn+LI51GwSnqCMyp4K67AXf9NxEZ3TvlUQws6LlSFMTPkU9LZBSC2H l2ibwcrKeOMq3GTalQO66CyQQPCPr5FW+BY4BHkIZ3RBr4FvaIIOsVxJ4kk+RMbV1zmH Ee43gE4WGwE3IhNWddvSNzFXD9fyYVyI0d578GB4NfbaESguGMP7fy9xtvkpRI8ZV+0Y +xAhRtqQ4uvl6e4xfBLGJQ83sO8nQRL0+GtvCMV++Qb7JBCKBy1NxNCm7+QgRvYTlrCS eeaA==
X-Received: by 10.194.89.67 with SMTP id bm3mr18088332wjb.80.1411664562218; Thu, 25 Sep 2014 10:02:42 -0700 (PDT)
Received: from [192.168.1.100] (IGLD-84-228-177-30.inter.net.il. [84.228.177.30]) by mx.google.com with ESMTPSA id dc9sm9870168wib.5.2014.09.25.10.02.41 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Sep 2014 10:02:41 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <21539.64527.894355.115813@fireball.kivinen.iki.fi>
Date: Thu, 25 Sep 2014 20:02:38 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <27AE385F-75F6-4EE3-8133-44A30DE955CB@gmail.com>
References: <541F2C84.7050805@gmail.com> <9A31C308-7D58-46EA-9CB5-47692A32E423@gmail.com> <31304.1411496671@sandelman.ca> <21539.64527.894355.115813@fireball.kivinen.iki.fi>
To: Tero Kivinen <kivinen@iki.fi>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/1PaM1ovIFpenl1vdfw1MyD8FgLg
Cc: ipsec <ipsec@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
Subject: Re: [IPsec] Call for adoption: Client Puzzles
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Sep 2014 17:02:45 -0000

On Sep 25, 2014, at 2:27 PM, Tero Kivinen <kivinen@iki.fi> wrote:

> Michael Richardson writes:
>> Yoav Nir <ynir.ietf@gmail.com> wrote:
>>> One proposal that I kind of liked (and I=92m sorry I=92ve forgotten =
who
>>> suggested it) was to relegate the puzzle to a second line of =
defense,
>>> through the use of some kind of anti-dos ticket. The ticket would be =
a
>>> bearer token (perhaps an encrypted timestamp) that would allow the
>>> bearer to get by with a much easier version of the puzzle. The
>>=20
>> Would this ticket be provided in a Notify, after AUTHentication, in a
>> previous PARENT-SA?
>=20
> Wouldn't it be better to use IKEv2 session resumption (RFC 5723) for
> those clients coming back.
>=20
> I.e if you resume old existing session then you do not need to do
> puzzle... And after the resume, the ticket is usually changed again,
> so the ticket would always be fresh.

That=92s possible. But session tickets are different from these tickets =
in two ways:

 1. Session tickets are time-limited with a rather short validity =
period. If policy requires checking the certificate / password every two =
hours, then the ticket cannot be valid for more than that.=20
 2. Session tickets must not be replayed, so the gateway has to use some =
very strict anti-replay mechanisms.

The proposed tickets can be valid for a long time, and while replay =
prevention is desired, it doesn=92t need to be very strict.

This laxness has operational benefits. It=92s easier to implement in a =
cluster of gateways, and a ticket will be valid even for a user that =
hasn=92t connected in a while. This makes sense because the prize from a =
replayed RFC 5723 ticket is great - a valid, authenticated session. OTOH =
managing to replay this new kind of ticket only gets you a half-open SA =
without bothering to solve a puzzle.=20

Yoav



From nobody Fri Sep 26 03:27:12 2014
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D61E1A1AC1 for <ipsec@ietfa.amsl.com>; Fri, 26 Sep 2014 03:27:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NP6dcCPHxhGm for <ipsec@ietfa.amsl.com>; Fri, 26 Sep 2014 03:27:08 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1CE11A1AC8 for <ipsec@ietf.org>; Fri, 26 Sep 2014 03:27:08 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id x13so6263100wgg.7 for <ipsec@ietf.org>; Fri, 26 Sep 2014 03:27:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5O1i/pHWdqPrHrIPVypaAx/ywd3I7ZQBwTW0i7eQgi0=; b=LkrtQ3FOrq2y5eMhW+50bcs+DBvDJORUdhbPDTkgq/XByqF+SuYnurtIW5btBqfa5T TyjcmU/6Bo1bmjbwUgtuCJUubCA901JaJZ4GjFvwB6Hj3EKzF+4X+WMbBC4YJbzPg7SW Z3JakGlmcu0y+Y5ajjBdh3AKnpqBZH/uH3qsyX639n72ZS+hoxeZUjx4eBdcUke76bWH LUIn0M3gBdcaiVU9zueWCi9jBosiBv/iJzc9t3f+MbHiGi3wqEXQaepo0mYdVolKkUjo ISPQ/mykrTiKRAB4VFJL7xWzUmohadannAjrW1yEs8Q9JTIEwEo4Lz9OZTQpmGrCVwOO bwag==
X-Received: by 10.194.5.234 with SMTP id v10mr22675191wjv.45.1411727227285; Fri, 26 Sep 2014 03:27:07 -0700 (PDT)
Received: from [10.0.0.6] (bzq-79-182-147-219.red.bezeqint.net. [79.182.147.219]) by mx.google.com with ESMTPSA id ks10sm5616008wjb.38.2014.09.26.03.27.05 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Sep 2014 03:27:06 -0700 (PDT)
Message-ID: <54253F78.3060805@gmail.com>
Date: Fri, 26 Sep 2014 13:27:04 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Yoav Nir <ynir.ietf@gmail.com>, Tero Kivinen <kivinen@iki.fi>
References: <541F2C84.7050805@gmail.com> <9A31C308-7D58-46EA-9CB5-47692A32E423@gmail.com> <31304.1411496671@sandelman.ca> <21539.64527.894355.115813@fireball.kivinen.iki.fi> <27AE385F-75F6-4EE3-8133-44A30DE955CB@gmail.com>
In-Reply-To: <27AE385F-75F6-4EE3-8133-44A30DE955CB@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/BCBI0Lj7foU2OtFc_56BFVv4KkM
Cc: ipsec <ipsec@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
Subject: Re: [IPsec] Call for adoption: Client Puzzles
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Sep 2014 10:27:11 -0000

I agree that if session resumption is implemented, it is a good way to 
reduce the problem drastically. Resuming clients go to the "fast track", 
and any new connections get the anti-DOS treatment - cookie- or 
puzzle-based.

To answer Yoav's two objections:

1. This is a standard trade-off. We can only hope people will eventually 
find a way to notify the IKE gateway when a password is changed, which 
would enable longer ticket lifetimes.

2. Quoting RFC 5723:

    This document therefore requires that the ticket be presented to the
    IKEv2 responder only once; under normal circumstances (e.g., no
    active attacker), there should be no multiple use of the same ticket.

    We are not aware of additional security issues associated with ticket
    reuse: the protocol guarantees freshness of the generated crypto
    material even in such cases.  As noted in Section 4.3.1, the gateway
    SHOULD prevent multiple uses of the same ticket.  But this is only an
    extra precaution, to ensure that clients do not implement reuse.  In
    other words, the gateway is not expected to cache old tickets for
    extended periods of time.

Thanks,
	Yaron


On 09/25/2014 08:02 PM, Yoav Nir wrote:
>
> On Sep 25, 2014, at 2:27 PM, Tero Kivinen <kivinen@iki.fi> wrote:
>
>> Michael Richardson writes:
>>> Yoav Nir <ynir.ietf@gmail.com> wrote:
>>>> One proposal that I kind of liked (and I�m sorry I�ve forgotten who
>>>> suggested it) was to relegate the puzzle to a second line of defense,
>>>> through the use of some kind of anti-dos ticket. The ticket would be a
>>>> bearer token (perhaps an encrypted timestamp) that would allow the
>>>> bearer to get by with a much easier version of the puzzle. The
>>>
>>> Would this ticket be provided in a Notify, after AUTHentication, in a
>>> previous PARENT-SA?
>>
>> Wouldn't it be better to use IKEv2 session resumption (RFC 5723) for
>> those clients coming back.
>>
>> I.e if you resume old existing session then you do not need to do
>> puzzle... And after the resume, the ticket is usually changed again,
>> so the ticket would always be fresh.
>
> That�s possible. But session tickets are different from these tickets in two ways:
>
>   1. Session tickets are time-limited with a rather short validity period. If policy requires checking the certificate / password every two hours, then the ticket cannot be valid for more than that.
>   2. Session tickets must not be replayed, so the gateway has to use some very strict anti-replay mechanisms.
>
> The proposed tickets can be valid for a long time, and while replay prevention is desired, it doesn�t need to be very strict.
>
> This laxness has operational benefits. It�s easier to implement in a cluster of gateways, and a ticket will be valid even for a user that hasn�t connected in a while. This makes sense because the prize from a replayed RFC 5723 ticket is great - a valid, authenticated session. OTOH managing to replay this new kind of ticket only gets you a half-open SA without bothering to solve a puzzle.
>
> Yoav
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


From nobody Fri Sep 26 05:16:55 2014
Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61ABA1A1B59 for <ipsec@ietfa.amsl.com>; Fri, 26 Sep 2014 05:16:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level: 
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQU1r3-spxgo for <ipsec@ietfa.amsl.com>; Fri, 26 Sep 2014 05:16:51 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA731A1B5E for <ipsec@ietf.org>; Fri, 26 Sep 2014 05:16:49 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s8QCGiT4026557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Sep 2014 15:16:44 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s8QCGioN012176; Fri, 26 Sep 2014 15:16:44 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-ID: <21541.22828.712971.615463@fireball.kivinen.iki.fi>
Date: Fri, 26 Sep 2014 15:16:44 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <27AE385F-75F6-4EE3-8133-44A30DE955CB@gmail.com>
References: <541F2C84.7050805@gmail.com> <9A31C308-7D58-46EA-9CB5-47692A32E423@gmail.com> <31304.1411496671@sandelman.ca> <21539.64527.894355.115813@fireball.kivinen.iki.fi> <27AE385F-75F6-4EE3-8133-44A30DE955CB@gmail.com>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 9 min
X-Total-Time: 10 min
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/x1nCm5swUZTkqXLAwEDv_bRk3Dc
Cc: ipsec <ipsec@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
Subject: Re: [IPsec] Call for adoption: Client Puzzles
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Sep 2014 12:16:53 -0000

Yoav Nir writes:
> > Wouldn't it be better to use IKEv2 session resumption (RFC 5723) fo=
r
> > those clients coming back.
> >=20
> > I.e if you resume old existing session then you do not need to do
> > puzzle... And after the resume, the ticket is usually changed again=
,
> > so the ticket would always be fresh.
>=20
> That=E2=80=99s possible. But session tickets are different from these=

> tickets in two ways:=20
>=20
>  1. Session tickets are time-limited with a rather short validity
>  period. If policy requires checking the certificate / password
>  every two hours, then the ticket cannot be valid for more than
>  that. =20

I do not think there is anything fundamental in session resumption
that requires them to have short validity period. The server can of
course remember which cert was uesd to authenticate the connection
originally and do OCSP check or check the cert against CRL when
connection is resumed.

Also server can also whiteliste the IP after the resumption is
successfull and then immediately require reauthentication from the
client by using RFC4478 AUTH=5FLIFETIME notification with lifetime of 0=
.=20

>  2. Session tickets must not be replayed, so the gateway has to use
>  some very strict anti-replay mechanisms.

The best way would be for the server to reissue now ticket for every
time client comes back. And server needs to check those tickets
anyways and keep track of them and make sure they are not reused...=20

> The proposed tickets can be valid for a long time, and while replay
> prevention is desired, it doesn=E2=80=99t need to be very strict.

I would assume each ticket only works once, and once you have
connected successfully you get new ticket. If attacker somehow can get
the ticket from the client (i.e. sees the connection attempt and
blocks the client while at the same time stealing the ticket), then it
can connect the server, but as it does not know the associated keying
material, it will be able to create only half-open SA and in that case
the server can just count such attempt and revoce the ticket after 3rd
failed attempt or so.=20

> This laxness has operational benefits. It=E2=80=99s easier to impleme=
nt in a
> cluster of gateways, and a ticket will be valid even for a user that
> hasn=E2=80=99t connected in a while. This makes sense because the pri=
ze from
> a replayed RFC 5723 ticket is great - a valid, authenticated
> session. OTOH managing to replay this new kind of ticket only gets
> you a half-open SA without bothering to solve a puzzle. =20

Yes.
--=20
kivinen@iki.fi


From nobody Fri Sep 26 06:08:39 2014
Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348361A6F5B for <ipsec@ietfa.amsl.com>; Fri, 26 Sep 2014 06:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.599
X-Spam-Level: 
X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMIK5dBEnen2 for <ipsec@ietfa.amsl.com>; Fri, 26 Sep 2014 06:08:33 -0700 (PDT)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12E0D1A6F42 for <ipsec@ietf.org>; Fri, 26 Sep 2014 06:08:32 -0700 (PDT)
Received: by mail-la0-f45.google.com with SMTP id q1so2824961lam.4 for <ipsec@ietf.org>; Fri, 26 Sep 2014 06:08:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:from:to:references:subject:date:mime-version :content-type; bh=ZjYut1buO2RJwBQ+klpK9HpO5Iji6FPJ2ijIADrXq/E=; b=Iy0uxSSDusOTOtscAHqhxyH4qjZesofRKcnvHKauiiZgzPMeCZAn7YnucIhAd11vF0 FqQh/cHAvnji7fXd89A7hZD7ZAuH4dhdEijNHhVblGgtWYFxu+KZZx1UmPON1SIK7eaW 1K2OwJIunwDuvSqI0phQhM42NuQ09UQH2ad2GToVb0eUsAaIQE6cKDJ1iIZDVEmEXSh1 pQ+8kv7OdsMsALZUyOEdnegIQujN4r8czHmtaZjWuVYwrsbQ5RkyGXC9ott/zTlQYc+R OY9H8nWk7lTT+hLDkiguOBteQN614b+jxG/adYckz5Qm/PqrYZCIJ3mU3l2tDgPTst5Q dXKg==
X-Received: by 10.152.121.8 with SMTP id lg8mr2555444lab.98.1411736911308; Fri, 26 Sep 2014 06:08:31 -0700 (PDT)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id do8sm1886800lbc.30.2014.09.26.06.08.29 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 26 Sep 2014 06:08:30 -0700 (PDT)
Message-ID: <495265DC337148788A718C004863E2B8@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Yaron Sheffer" <yaronf.ietf@gmail.com>, "ipsec" <ipsec@ietf.org>
References: <541F2C84.7050805@gmail.com>
Date: Fri, 26 Sep 2014 17:08:51 +0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_018A_01CFD9AC.8BCB6A00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/p8FkydsHLOnhfDguwF0HFXJn1yU
Subject: Re: [IPsec] Call for adoption: Client Puzzles
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Sep 2014 13:08:35 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_018A_01CFD9AC.8BCB6A00
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

I think that the DoS protection is very important problem for IKE
and it needs to be addressed. I have, though, mixed feelings about=20
the draft in its current form. The idea is very cute, but it has
IMHO a limited usage in protection against DoS attack.=20
It doesn't protect against DDoS performed by botnets
and may even make the situation worse for legitimate clients.
So, I think more research is needed, althouth this idea
should be kept in mind.

Regards,
Valery.

  ----- Original Message -----=20
  From: Yaron Sheffer=20
  To: ipsec=20
  Sent: Sunday, September 21, 2014 11:52 PM
  Subject: [IPsec] Call for adoption: Client Puzzles


Dear working group,

This is a call for adopting draft-nir-ipsecme-puzzles-00 as a WG =
document. Please respond to this mail with a Yes or No and a short =
rationale, at latest by Friday Sep. 26.


Thanks,
	Yaron



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


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

------=_NextPart_000_018A_01CFD9AC.8BCB6A00
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML style=3D"DIRECTION: ltr"><HEAD>
<META content=3D"text/html; charset=3Dutf-8" http-equiv=3Dcontent-type>
<STYLE type=3Dtext/css>BODY P {
	MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0cm
}
</STYLE>

<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.23588"></HEAD>
<BODY style=3D"DIRECTION: ltr" bgColor=3D#ffffff text=3D#000000=20
bidimailui-charset-is-forced=3D"true">
<DIV><FONT size=3D2>Hi,</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>I think that the DoS protection is very important =
problem for=20
IKE</FONT></DIV>
<DIV><FONT size=3D2>and it needs to be addressed. I have, though, mixed =
feelings=20
about </FONT></DIV>
<DIV><FONT size=3D2>the draft in its current form. The idea is very =
cute, but it=20
has</FONT></DIV>
<DIV><FONT size=3D2>IMHO a limited usage in protection against DoS =
attack.=20
</FONT></DIV>
<DIV><FONT size=3D2>It doesn't protect against DDoS performed by=20
botnets</FONT></DIV>
<DIV><FONT size=3D2>and may even make the situation worse for legitimate =

clients.</FONT></DIV>
<DIV><FONT size=3D2>So, I think more research is needed, althouth this=20
idea</FONT></DIV>
<DIV><FONT size=3D2>should be kept in mind.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Regards,</FONT></DIV>
<DIV><FONT size=3D2>Valery.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; =
PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"FONT: 10pt arial; BACKGROUND: #e4e4e4; font-color: =
black"><B>From:</B>=20
  <A title=3Dyaronf.ietf@gmail.com =
href=3D"mailto:yaronf.ietf@gmail.com">Yaron=20
  Sheffer</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A title=3Dipsec@ietf.org=20
  href=3D"mailto:ipsec@ietf.org">ipsec</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Sunday, September 21, =
2014 11:52=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [IPsec] Call for =
adoption:=20
  Client Puzzles</DIV>
  <DIV><BR></DIV><FONT color=3D#000000><PRE style=3D"MARGIN: 0em">Dear =
working group,

</PRE><TT>This is a call for adopting draft-nir-ipsecme-puzzles-00 as a=20
  </TT><TT>WG document. Please respond to this mail with a Yes or No and =
a short=20
  </TT><TT>rationale, at latest by Friday Sep. 26.<BR><BR></TT><PRE =
style=3D"MARGIN: 0em">Thanks,
	Yaron

</PRE></FONT>
  <P>
  <HR>

  <P></P>_______________________________________________<BR>IPsec =
mailing=20
  list<BR><A href=3D"mailto:IPsec@ietf.org">IPsec@ietf.org</A><BR><A=20
  =
href=3D"https://www.ietf.org/mailman/listinfo/ipsec">https://www.ietf.org=
/mailman/listinfo/ipsec</A><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_018A_01CFD9AC.8BCB6A00--


From nobody Sun Sep 28 19:30:10 2014
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BA31A6F86 for <ipsec@ietfa.amsl.com>; Sun, 28 Sep 2014 19:30:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.647
X-Spam-Level: 
X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmkVRNLQqFTg for <ipsec@ietfa.amsl.com>; Sun, 28 Sep 2014 19:30:04 -0700 (PDT)
Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AB0F1A6F85 for <ipsec@ietf.org>; Sun, 28 Sep 2014 19:30:04 -0700 (PDT)
Received: from [10.20.30.90] (142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s8T2U1xe007214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <ipsec@ietf.org>; Sun, 28 Sep 2014 19:30:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: proper.com: Host 142-254-17-87.dsl.dynamic.fusionbroadband.com [142.254.17.87] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <541F2C84.7050805@gmail.com>
Date: Sun, 28 Sep 2014 19:30:00 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <359A7BBE-22E7-4BDF-8435-C06860701E9B@vpnc.org>
References: <541F2C84.7050805@gmail.com>
To: ipsec <ipsec@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/d5e86jvBAwyp0WfNuf31vZXYKXk
Subject: Re: [IPsec] Call for adoption: Client Puzzles
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Sep 2014 02:30:07 -0000

The call for adoption has had mixed results. On the one hand, there is =
lots of interest in working on the problem. On the other, there is a =
fair amount of trepidation about whether making things significantly =
harder for botnets is attainable with the current state of botnets and =
puzzles is achievable; if it is not, maybe we shouldn't add another =
extensions that could make IKEv2 more fragile.

Given the interest, though, we will adopt this as a WG item. However, =
given the trepidation, we might purposely abandon the work later if we =
think we are not able to make a useful mechanism.

--Paul Hoffman=


From nobody Mon Sep 29 06:26:59 2014
Return-Path: <mcr@sandelman.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6EC1A1BCB for <ipsec@ietfa.amsl.com>; Mon, 29 Sep 2014 06:26:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.778
X-Spam-Level: 
X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlO7nNHsJ4fE for <ipsec@ietfa.amsl.com>; Mon, 29 Sep 2014 06:26:50 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 225271A1AFF for <ipsec@ietf.org>; Mon, 29 Sep 2014 06:26:50 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1B75420028; Mon, 29 Sep 2014 09:32:22 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 23B4E63AE9; Mon, 29 Sep 2014 09:26:48 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 086CD637FC; Mon, 29 Sep 2014 09:26:48 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <359A7BBE-22E7-4BDF-8435-C06860701E9B@vpnc.org>
References: <541F2C84.7050805@gmail.com> <359A7BBE-22E7-4BDF-8435-C06860701E9B@vpnc.org>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 29 Sep 2014 09:26:48 -0400
Message-ID: <13992.1411997208@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Fpg9U9jC65M4EXYtMPVf9OUWeCs
Cc: ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] Call for adoption: Client Puzzles
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Sep 2014 13:26:55 -0000

--=-=-=


Paul Hoffman <paul.hoffman@vpnc.org> wrote:
    > Given the interest, though, we will adopt this as a WG item. However,
    > given the trepidation, we might purposely abandon the work later if we
    > think we are not able to make a useful mechanism.

Thank you.

I think that this is the best process;  I think we need to think about the
problem deeper.  It would be nice if it could be made to work; but I suspect
that may be equivalent to the CAPTCHA problem.

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




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

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

iQEVAwUBVCleFYCLcPvd0N1lAQLX/gf/Wu6AlillPDwuhR0745u4Ycmg9HYL7C0N
ZU5ZI3UjmmdbARU8zsCLyFnTYN6wTB8GaJOHe6d46DkOooKnbDTGkWR0IoIrDcsF
044Vg3vpJewRE/ZvJeQUd0lItJUfqlqMAva6pr9hi3Yw4JrB6SZEq6JNGFgu0PjT
3s0jFJXg70KcERYnFm2BVwiN+tWFwLpaphREWufW8mxRP1JlUpoSW/vqWy8TDb4N
ur5DLj1s2ZTFkmMvf6Pp46XwNRZ9U3jwWvtGS39MNETqoue/yAe6B/OMPjrEHjel
kIMrS5lSKJAR3rtJtTebtyNGD50wLVBFlRnulvHH7BxaTmzFOJK04w==
=4N3M
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Tue Sep 30 03:44:00 2014
Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0611A032A for <ipsec@ietfa.amsl.com>; Tue, 30 Sep 2014 03:43:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level: 
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5GqGaL_Fx4Z for <ipsec@ietfa.amsl.com>; Tue, 30 Sep 2014 03:43:56 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A5321A031B for <ipsec@ietf.org>; Tue, 30 Sep 2014 03:43:55 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s8UAhoGY017682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Sep 2014 13:43:50 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s8UAhn1M018282; Tue, 30 Sep 2014 13:43:49 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21546.35173.105704.345146@fireball.kivinen.iki.fi>
Date: Tue, 30 Sep 2014 13:43:49 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Michael Richardson <mcr+ietf@sandelman.ca>
In-Reply-To: <13992.1411997208@sandelman.ca>
References: <541F2C84.7050805@gmail.com> <359A7BBE-22E7-4BDF-8435-C06860701E9B@vpnc.org> <13992.1411997208@sandelman.ca>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 33 min
X-Total-Time: 109 min
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/UkFal0kZFuLi6c-Uzri8Yn5Lzm0
Cc: ipsec <ipsec@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [IPsec] Call for adoption: Client Puzzles
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Sep 2014 10:43:59 -0000

Michael Richardson writes:
> I think that this is the best process;  I think we need to think about the
> problem deeper.  It would be nice if it could be made to work; but I suspect
> that may be equivalent to the CAPTCHA problem.

I do think the problem is easier than that...

I think the solution is combination of the protocol and the policy
rules. If we make some assumptions:

1) Gateway is NOT constrained device. It is device that can store some
data (few tens of megabytes of data when under attack is possible).

2) Client can be constrained device, which do not have lots of CPU
power or memory. If it is really constrained device, then it usually
isn't interactive connection, so even if it needs to wait for a while
to get connection that is ok. 

3) Client can also be smartphone, i.e. device which have quite a lot
of CPU power and/or memory, but does not want to use it as it would
increase the power usage so much that the battery life will be
shortened.

4) Client can also be desktop, i.e. device with quite a lot of CPU
power and/or memory, and who is not afraid of using those :-)

5) Each connections are usually quite long lived, i.e. devices make
one connection to the gateway, and keep that connection up all the
time, or at least very long time. If they move they use MOBIKE to keep
IKEv2 up and running even when they change IP-addresses. If they go
sleep for long time or disconnect from the network they will use
session resumption to come back.

6) Gateway can use IKEv2 redirect to distribute the attackers, i.e. it
could even use some cloud service which provides first level
protection, i.e. first redirect client during IKE_SA_INIT to cloud
service with LOTS of computing power. Then the cloud service will
authenticate client but might not authenticate the server (for example
using one way authentication). When the server then redirect client
back to real server using redirect, it will provide some kind of
VIP-pass cookie, that allows client to get past the queue... Or if the
SGW is willing to give authentication information to the cloud, the
server authentication can be done normally in cloud service, and
resumption token given to the client, and then client can be
redirected back to the original server. There are probably some open
issues how this all is done and how to combine redirect, resumption
and all those, but the protocol elements are there (except VIP-pass
cookie).

7) Botnets have huge amount of CPU power and lots of memory, but still
limited number of distinguished IPv4-addresses or IPv6-prefixes (it
might be millions, but most likely around thousands or tens of
thousands IP-addresses).

So I think those above make it easier than the captcha problem...

Also the gateway can blacklist all failed attempts by clients, i.e. do
not accept new connections from the same IP-address for some amount of
seconds, or move them to end of queue.

This assume that the blacklist for each failed attempt by IP-address
would be few tens of megabytes of memory, if attacker has about
million IP-addresses/prefixes. Note, that we can also make the prefix
length adjustable, i.e. assume attackers are not too close (related to
the IP-addresses) to the real users, and instead of /64 we could use
/56 or /48 for IPv6-addresses and /28 or /24 for IPv4 addresses. This
would reduce the size of the blacklist table. 

I would expect the processing rules being so that we collect new
connections for some amount of time, for example 100 ms, then we sort
the new connection attemps using special rules for that. We would move
everybody having valid resumption ticket or VIP-pass to the front,
then we would move everybody with IP-address blacklisted to the end
(ordered by number of failed attempts), and finally sort rest using
some kind of sorting order which would include whether they have
cookie or not, how long puzzle they have solved etc.

Now after we have the sorted list, we take first connection from the
list, start processing it, after that take next etc. While we are
processing current queue, we collect next batch of request. Then after
interval is passed again (i.e. after 100 ms), we throw the old queue
away (or keep the resumption and VIP-pass clients still in queue),
create new queue, and start over.

So I think the solution is something we can get working, and it will
be combination of differnet protocols we already have, and some new
protocols like the puzzle, and then it also includes description how
to combine all of those.
-- 
kivinen@iki.fi


From nobody Tue Sep 30 06:54:24 2014
Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08EBC1A1A1B for <ipsec@ietfa.amsl.com>; Tue, 30 Sep 2014 06:54:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.786
X-Spam-Level: 
X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzJF4afTcIfN for <ipsec@ietfa.amsl.com>; Tue, 30 Sep 2014 06:54:12 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9B951A1A17 for <ipsec@ietf.org>; Tue, 30 Sep 2014 06:54:11 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BAED980055; Tue, 30 Sep 2014 09:54:09 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1412085249; bh=ml3LKl0AqvjvdHVRvmATEdMIyAdDWwFTWcFTPoew1Ys=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Bf7ojdkjTilk88btTIG7AXoBM5ly9VauYx+6wV7fmkmPBteojOIbAPfDyNsPVJpFS ErhOAnRbwT4ShX0Nu/eqRanGf7IEE1vKmcOSUi1olMAvZGoHTcgyfGOtPjL2FMAEWM rr7s1DQJgw2+If9FHgKAU5uE0rIDmra+uw6/RWcU=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s8UDs8aV028867; Tue, 30 Sep 2014 09:54:09 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Tue, 30 Sep 2014 09:54:08 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Tero Kivinen <kivinen@iki.fi>
In-Reply-To: <21546.35173.105704.345146@fireball.kivinen.iki.fi>
Message-ID: <alpine.LFD.2.10.1409300948100.15380@bofh.nohats.ca>
References: <541F2C84.7050805@gmail.com> <359A7BBE-22E7-4BDF-8435-C06860701E9B@vpnc.org> <13992.1411997208@sandelman.ca> <21546.35173.105704.345146@fireball.kivinen.iki.fi>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/lyDpzKnVnhc17EO8EZv30gPLGqk
Cc: ipsec <ipsec@ietf.org>
Subject: Re: [IPsec] Call for adoption: Client Puzzles
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Sep 2014 13:54:17 -0000

On Tue, 30 Sep 2014, Tero Kivinen wrote:

> 5) Each connections are usually quite long lived, i.e. devices make
> one connection to the gateway, and keep that connection up all the
> time, or at least very long time.

Can I have a pony with that? :)

My experience is seeing many many short lives connections. Stupidly
short, sucking the life out of the battery short.

> 6) Gateway can use IKEv2 redirect to distribute the attackers, i.e. it
> could even use some cloud service which provides first level
> protection

Interesting, but very scary....

> Also the gateway can blacklist all failed attempts by clients, i.e. do
> not accept new connections from the same IP-address for some amount of
> seconds, or move them to end of queue.

That's too easy a DOS to abuse.

> So I think the solution is something we can get working, and it will
> be combination of differnet protocols we already have, and some new
> protocols like the puzzle, and then it also includes description how
> to combine all of those.

Moar bells and whistles! :)

Paul


From nobody Tue Sep 30 10:43:19 2014
Return-Path: <mcr@sandelman.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A7B1A6FF2 for <ipsec@ietfa.amsl.com>; Tue, 30 Sep 2014 10:43:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpP88s5b-DiM for <ipsec@ietfa.amsl.com>; Tue, 30 Sep 2014 10:43:15 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B8B1A6FE9 for <ipsec@ietf.org>; Tue, 30 Sep 2014 10:43:15 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 687E620012; Tue, 30 Sep 2014 13:48:51 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 745CA63AE9; Tue, 30 Sep 2014 13:43:13 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5EC90637FC; Tue, 30 Sep 2014 13:43:13 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Tero Kivinen <kivinen@iki.fi>
In-Reply-To: <21546.35173.105704.345146@fireball.kivinen.iki.fi>
References: <541F2C84.7050805@gmail.com> <359A7BBE-22E7-4BDF-8435-C06860701E9B@vpnc.org> <13992.1411997208@sandelman.ca> <21546.35173.105704.345146@fireball.kivinen.iki.fi>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Tue, 30 Sep 2014 13:43:13 -0400
Message-ID: <22982.1412098993@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/IEtI39CF3TK6AdZYDZWhWhYJgAA
Cc: ipsec <ipsec@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [IPsec] Call for adoption: Client Puzzles
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Sep 2014 17:43:18 -0000

--=-=-=


Tero Kivinen <kivinen@iki.fi> wrote:
    > 3) Client can also be smartphone, i.e. device which have quite a lot of
    > CPU power and/or memory, but does not want to use it as it would
    > increase the power usage so much that the battery life will be
    > shortened.

Except that client being smartphone/etc. is behind NAT44, and along with
ten thousand other smartphones, all have the same IP address... this matters
because that scenario is probably indistinguishable from:

    > 7) Botnets have huge amount of CPU power and lots of memory, but still
    > limited number of distinguished IPv4-addresses or IPv6-prefixes (it
    > might be millions, but most likely around thousands or tens of
    > thousands IP-addresses).

a situation where there is an enterprise of compromised systems behind
the enterprise firewall. (University lab networks come to mind...)

Further, the botnets don't need to present thousands of distinguished IPv4
addresses, they can present a small number of attack nodes, spreading the
work across the botnet?

So this tells me that we are looking for puzzles which are *not*
parallelizable.   I know little about this kind of stuff...

    > So I think those above make it easier than the captcha problem...

    > Also the gateway can blacklist all failed attempts by clients, i.e. do
    > not accept new connections from the same IP-address for some amount of
    > seconds, or move them to end of queue.

Move them to the end of the queue makes most sense.

    > I would expect the processing rules being so that we collect new
    > connections for some amount of time, for example 100 ms, then we sort
    > the new connection attemps using special rules for that. We would move
    > everybody having valid resumption ticket or VIP-pass to the front, then
    > we would move everybody with IP-address blacklisted to the end (ordered
    > by number of failed attempts), and finally sort rest using some kind of
    > sorting order which would include whether they have cookie or not, how
    > long puzzle they have solved etc.

    > Now after we have the sorted list, we take first connection from the
    > list, start processing it, after that take next etc. While we are
    > processing current queue, we collect next batch of request. Then after
    > interval is passed again (i.e. after 100 ms), we throw the old queue
    > away (or keep the resumption and VIP-pass clients still in queue),
    > create new queue, and start over.

    > So I think the solution is something we can get working, and it will be
    > combination of differnet protocols we already have, and some new
    > protocols like the puzzle, and then it also includes description how to
    > combine all of those.

I think if the gateway has multiple CPUs, that it can collect and process at
the same time, it just has to never commit more than n-2 CPUs towards
processing so that it can have CPU left over for the collecting/sorting, and
of course, for other stuff like, say, IPsec...

I suspect, however, that the simplest machines to DDoS will be the smallest
gateways.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


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




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

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

iQEVAwUBVCrrsYCLcPvd0N1lAQIa6gf/Z0mA3BcDFA8pQlWPObAlOMEk2+6q9rH2
P619NFR0p5q/N1Tc3xmRywK+rbuAu7kmnTrdXDmTjtuKp7n0qGQT7MhE1dHvkKaU
WKsjHWSFJelgBqIR28eae8V4Z6Xw9SCi1kAjXBFiGHILFqYM/vm3gYvta5OLyhHG
zXvQAHhMOrLiDLDTNsyrpXPAbgfdpfHIv889jqB/fjNxo/haOPE0NUNAza5t7AM5
LF+qvAwMdLvBlTuU7OKUxN2ZTwz0M8ZxOpxRdVk9glqcqwmzKWhoZ6MayiT422AA
pQ1kdbOTkMzvOpRQ15l4PyTbx4/IFxYpolOpf3E6bzQLWRjzo1rLNA==
=kT6h
-----END PGP SIGNATURE-----
--=-=-=--